Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 1 Jan 2016 20:23:21 +0100
richard lucassen  wrote:

> Ok, I think we agree. But as OP said: it would be very nice to get rid
> of initramfs. But for a distribution kernel this would be almost
> undoable. So what about the idea to just have an initrd containing all
> necessary modules for mounting / ? The rest can be loaded once the /
> fs has been mounted.

And of course, as suggested by Didier, build in a few popular
filesystems. In these cases an initrd can be omitted. That keeps things
simple IMHO.

R.

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

Didier Kryn  writes:
> Le 01/01/2016 20:05, Rainer Weikusat a écrit :
>> richard lucassen  writes:
>>> Rainer Weikusat  wrote:
> Plus the drivers for various hardware like cciss devices, just
> having ext4 built in is not enough. Wouldn't it be better to have a
> simple initramfs with just the apropiate modules for the hardware?
 No computer I've either been using privately or professionally ever
 suddenly grew a new motherboard (simplification) overnight. Hence,
 they're all running kernels with the drivers and filesystems necessary
 for booting compiled in.
>>> Of course, but I presume that we're talking about a kernel that will be
>>> distributed by Devuan. If you build in hardware drivers for all
>>> different types of hardware, the kernel gets somewhat big IMHO ;-)
>> Some signals crossed here. I was trying to explain that "a distribution"
>> has to use initrd/ initramfs because of problems specific to
>> distribution kernels but that individual users don't have to use this
>> mechanism if they don't want to because they can just compile a kernel
>> which will work with their hardware (which is usually rather static).
>
> There might be an optional kernel featuring sata, scsi and a few
> popular filesystems. That would match the vast majority of cases.

SCSI is a protocol for accessing storage devices. ATA is also a protocol
for accessing storage devices. SATA is ATA over a single cable (instead
of sixteen parallell cables). There's also SAS (serial-attached SCSI).
But all of this still doesn't get anyone anywhere as drivers are needed
to work with individual SATA or SCSI or SAS controllers. There's a de
facto standard SATA hardware interface called AHCI (defined by Intel)
which only needs an AHCI driver module but there are all kinds of other
SATA implementations not conforming to it. Nothing similar exists for
SCSI/ SAS interfaces.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FW: support for merged /usr in Debian

[Stephanie Daugherty]

Regardless of who proposed it, merged /usr is still a reckless change that
needlessly complicates things.

The /usr and / split hasn't been perfectly followed, ever, but, still
achieves the goal of having a system that can be recovered from various
problems easily.

I should be able to substitute /bin/sh for init, and directly mount / and
go from there to a fully working system, regardless of my partitioning.
Period. If I can no longer do that, it's a broken system.




On Fri, Jan 1, 2016 at 9:25 PM, Steve Litt 
wrote:

> On Fri, 1 Jan 2016 19:33:41 +0100
> Didier Kryn  wrote:
>
> > Le 01/01/2016 18:07, Steve Litt a écrit :
> > > On Fri, 01 Jan 2016 15:45:49 +0100
> > > Micky Del Favero  wrote:
> > >
> > >> Daniel Reurich  writes:
> > >>
> > >>> So the potteringisation continues...
> > >> If I remember well Solaris has /bin linked to /usr/bin since many
> > >> years, so linking /bin to /usr/bin is not a poetteringisation, or
> > >> almost it's not an original idea of poettering.
> > >>
> > >> Ciao, Micky
> > > Well, OK, if we're really going to discuss this...
> > >
> > > This *is* poetterization, regardless of what Sun or anyone else did
> > > before. It's supported by Freedesktop.org, and I think everyone
> > > here can agree that anything Freedesktop supports is anti-init
> > > choice, anti-simplicity, anti-modularity, and pro-systemd.
> > >
> > >
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> > >
> > > Those of you who have tried to lay down an alternate init system, to
> > > replace systemd, without the aid of a package manager, will probably
> > > agree with me that the toughest obstacle isn't udev, it isn't dbus,
> > > it's initramfs. I looked up the word "black box" in the dictionary
> > > last night, and they had a picture of initramfs.
> > >
> > > Hey, I'll be the first to admit that sometimes you need an
> > > initramfs. Maybe you have LUKS plus LVM plus software raid. Merge
> > > or not, you'll need to compile yourself one heck of a kernel to
> > > avoid needing initramfs. But for the very prevalent use case of
> > > Ext4, no raid, no LVM, no LUKS, no silly merge, and a few
> > > partitions, initramfs is as useful as udders on a snake. I mean
> > > seriously, in such a use case, you forego initramfs: boot to the
> > > root partition, run /sbin/mount -a, and bang, you have all
> > > resources available to you. But nooo.
> > >
> > > Initramfs does have one big benefit for the Poetterists: It
> > > provides a dark, safe place for them to start up their
> > > megacomplexities and call it magic. Oh, there are tools with which
> > > you can periscope into initramfs, but have you ever really looked
> > > at everything in an initramfs? It's a jungle in there. Just right
> > > for the Poetterists to incubate their plague.
> > >
> > > Now, the Freedesktop.Org to which I referred earlier in this email
> > > has a link to the following Rob Landley page explaining what they
> > > call the "historical reasons" for separate directories:
> > > jitsi_2.8.5426-1_amd64.deb
> > > http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
> > >
> > > Note that Landley's #1 reason for merging is the existance of
> > > initramfs. Now I'm not stupid enough to call the author of Busybox a
> > > Poetterist. He wrote this in 2010, before anyone really knew the
> > > Napoleonistic aspirations of systemd, back in the days when a
> > > complex and opaque "early boot" wasn't a big deal.
> > >
> > > But now it's 5 years later, and that early boot black box is exactly
> > > where the Poetterists fester most virulently.
> > >
> > > In summary, if you accept the merge and /usr on a separate
> > > partition, you need initramfs. And if you have initramfs, you've
> > > just made it three times as hard to lay down Runit or Epoch or s6
> > > or Suckless Init plus daemontools-encore plus Littkit.
> > >
> > > We all have to pick our own battles, and I'm not sure how much
> > > effort I'd make to roll back the merge. It may indeed be a good
> > > thing that only 3 changes are required to patch up Devuan for the
> > > merge. But make no mistake about it: regardless of its initial
> > > motivation, today the merge's primary beneficiaries are Red Hat and
> > > their proxies, Freedesktop.org and Lennart Poettering.
> > >
> > > SteveT
> > >
> >
> >  Sorry Steve but I think you are making some confusion.
> >
> >  Before initramfs, there was initrd for the same major purpose:
> > to load the necessary device driver to operate the hard disk drive.
> > initramfs is just more clever than initrd. The kernel developpers,
> > IIRC, have developped their own set of applications for use in the
> > initrsmfs/initrd.
> >
> >  Busybox OTH was not developped for initramfs at all, and Rob
> > Landley was only one of many developpers of Busybox (he's now
> > developping his own alternative). The fact is that Busybox 

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 1 Jan 2016 20:48:13 +0100
richard lucassen  wrote:

> And of course, as suggested by Didier, build in a few popular
> filesystems. In these cases an initrd can be omitted. That keeps
> things simple IMHO.

s/filesystems/hardware drivers/

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FW: support for merged /usr in Debian

[Micky Del Favero]

Steve Litt  writes:

> This *is* poetterization, regardless of what Sun or anyone else did
> before. It's supported by Freedesktop.org, and I think everyone here
> can agree that anything Freedesktop supports is anti-init choice,
> anti-simplicity, anti-modularity, and pro-systemd.

So anything freedesktop.org supports is a bad idea a priori only because
freedesktop.org supports systemd even if the same idea somebody else has
years ago before systemd?
For me this is a religion war drives by the same forma mentis of
poettering's: "#notabug #wontfix because it works for me".

> Hey, I'll be the first to admit that sometimes you need an initramfs.
> Maybe you have LUKS plus LVM plus software raid. Merge or not, you'll
> need to compile yourself one heck of a kernel to avoid needing
> initramfs. But for the very prevalent use case of Ext4, no raid, no
> LVM, no LUKS, no silly merge, and a few partitions, initramfs is as

Againg you're acting as poettering: if I've a system like yours with
ext4, without any raid or lvm or luks I can boot my system without
initramfs, if I have a different setup I'm a heretic man to be
converted.

Will Devuan become the universal operating system that Debian pre
systemd was or it'll only be the opposite of Debian? 

All my servers disks are formatted with xfs, on a lvm lv over raid
volume, all my computers disks are formatted xfs, on some computer I
also have luks volumes.

I can recompile the kernel so all needed modules are static compiled in
kernel, and all users that want a different setup than ext4 without
raid, lvm, luks or whatever, is it really what we want forcing users to
recompile kernels on a machine like yours to be able to boot their boxes
only because you don't like initramfs?

Maybe merging /bin in /usr/bin isn't a good idea, maybe it's, I cannot
see any problem merging /bin in /usr/bin, Solaris made it many yars ago
and it hasn't systemd and overall it runs without problem due to
merging, I also think that using initramfs is possible also having
separate direcroty for /usr and /usr/bin, as it's now.

> Initramfs does have one big benefit for the Poetterists: It provides a
> dark, safe place for them to start up their megacomplexities and call
> it magic. Oh, there are tools with which you can periscope into
> initramfs, but have you ever really looked at everything in an
> initramfs? It's a jungle in there. Just right for the Poetterists to
> incubate their plague.

years ago i've built a cluster of diskless servers that network booted
using a initramfs filesystem, it's not so obscure, I admit it wasn't
trivial to made the initramfs, but was simpler than you can think.

Ciao, Micky
-- 
The sysadmin has all the answers, expecially "No"
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Some useful X11 utilities (was: Re: Windowmaker: was Proposals for an xfce-desktop-lite )

[Joel Roth]

Quoting this with a useful subject.

Simon Wise wrote:
> I have been using dmenu for some time now ... with a couple of other tools
> that allow for a few tweaks to DEs to make them more comfortable for me, or
> indeed to set up kiosk style environments without any DE required at all.
> Use xbindkeys to set a hotkey ...
 
> xbindkeys
> is a way to get keybindings for commands easily, works anywhere in X, I have
> been using it to avoid each individual DEs different ways of doing things,
> and easily get some consistency no matter which DE I'm using.
> 
> triggerhappy (thd)
> does the job in embedded devices without X running, it gets the events
> directly from input devices.
> 
> devilspie
> can be a great help in setting specific window placements and such in X, it
> performs actions on newly opened windows.
> 
> alongside a few tools like xwit, xclip and a others, even xte for stubborn
> applications, you can tame X on even the smallest embedded device. And the
> main tools above have more sophisticated scheme or similar configuration
> options if you want to put a little work into getting a specific X
> environment right.
> 
> I'm using i3 as my desktop currently, it is very light, has few dependencies
> and will do most of the above without help (in a tiling environment)

Nice to see someone mention i3. Except for the rare
multipanel app such as gimp, I find i3 works well for my
needs. It seems faster to flip through the open tiled
windows with keyboard shortcuts than clicking and moving
windows on a desktop. 

cheers


-- 
Joel Roth
  

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

Re: [DNG] FW: support for merged /usr in Debian

[Daniel Reurich]

On 02/01/16 09:47, Micky Del Favero wrote:
> Steve Litt  writes:
> 
>> This *is* poetterization, regardless of what Sun or anyone else
>> did before. It's supported by Freedesktop.org, and I think everyone
>> here can agree that anything Freedesktop supports is anti-init
>> choice, anti-simplicity, anti-modularity, and pro-systemd.
> 
> So anything freedesktop.org supports is a bad idea a priori only
> because freedesktop.org supports systemd even if the same idea
> somebody else has years ago before systemd? For me this is a religion
> war drives by the same forma mentis of poettering's: "#notabug
> #wontfix because it works for me".

No, rather freedesktop.org and Poettering are largely synonomous.  Most
of what is proposed there lately is mostly either from Poettering or his
minions and a lot of what they propose is crap at best and destructive
to the non-systemd ecosystem at worst.
> 
>> Hey, I'll be the first to admit that sometimes you need an
>> initramfs. Maybe you have LUKS plus LVM plus software raid. Merge
>> or not, you'll need to compile yourself one heck of a kernel to
>> avoid needing initramfs. But for the very prevalent use case of
>> Ext4, no raid, no LVM, no LUKS, no silly merge, and a few
>> partitions, initramfs is as
> 
> Againg you're acting as poettering: if I've a system like yours with 
> ext4, without any raid or lvm or luks I can boot my system without 
> initramfs, if I have a different setup I'm a heretic man to be 
> converted.
> 
> Will Devuan become the universal operating system that Debian pre 
> systemd was or it'll only be the opposite of Debian?
> 
Devuan will continue to use an initramfs as a default is that is the
only sane approach that provides broad support for most use cases.  But
of course we will support users being able to have the choice to build
there own initramfs free system too.  They just have to build the
tooling needed for that approach as packages for devuan.



-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FW: support for merged /usr in Debian

[Steve Litt]

On Fri, 1 Jan 2016 19:33:41 +0100
Didier Kryn  wrote:

> Le 01/01/2016 18:07, Steve Litt a écrit :
> > On Fri, 01 Jan 2016 15:45:49 +0100
> > Micky Del Favero  wrote:
> >  
> >> Daniel Reurich  writes:
> >>  
> >>> So the potteringisation continues...  
> >> If I remember well Solaris has /bin linked to /usr/bin since many
> >> years, so linking /bin to /usr/bin is not a poetteringisation, or
> >> almost it's not an original idea of poettering.
> >>
> >> Ciao, Micky  
> > Well, OK, if we're really going to discuss this...
> >
> > This *is* poetterization, regardless of what Sun or anyone else did
> > before. It's supported by Freedesktop.org, and I think everyone
> > here can agree that anything Freedesktop supports is anti-init
> > choice, anti-simplicity, anti-modularity, and pro-systemd.
> >
> > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> >
> > Those of you who have tried to lay down an alternate init system, to
> > replace systemd, without the aid of a package manager, will probably
> > agree with me that the toughest obstacle isn't udev, it isn't dbus,
> > it's initramfs. I looked up the word "black box" in the dictionary
> > last night, and they had a picture of initramfs.
> >
> > Hey, I'll be the first to admit that sometimes you need an
> > initramfs. Maybe you have LUKS plus LVM plus software raid. Merge
> > or not, you'll need to compile yourself one heck of a kernel to
> > avoid needing initramfs. But for the very prevalent use case of
> > Ext4, no raid, no LVM, no LUKS, no silly merge, and a few
> > partitions, initramfs is as useful as udders on a snake. I mean
> > seriously, in such a use case, you forego initramfs: boot to the
> > root partition, run /sbin/mount -a, and bang, you have all
> > resources available to you. But nooo.
> >
> > Initramfs does have one big benefit for the Poetterists: It
> > provides a dark, safe place for them to start up their
> > megacomplexities and call it magic. Oh, there are tools with which
> > you can periscope into initramfs, but have you ever really looked
> > at everything in an initramfs? It's a jungle in there. Just right
> > for the Poetterists to incubate their plague.
> >
> > Now, the Freedesktop.Org to which I referred earlier in this email
> > has a link to the following Rob Landley page explaining what they
> > call the "historical reasons" for separate directories:
> > jitsi_2.8.5426-1_amd64.deb
> > http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
> >
> > Note that Landley's #1 reason for merging is the existance of
> > initramfs. Now I'm not stupid enough to call the author of Busybox a
> > Poetterist. He wrote this in 2010, before anyone really knew the
> > Napoleonistic aspirations of systemd, back in the days when a
> > complex and opaque "early boot" wasn't a big deal.
> >
> > But now it's 5 years later, and that early boot black box is exactly
> > where the Poetterists fester most virulently.
> >
> > In summary, if you accept the merge and /usr on a separate
> > partition, you need initramfs. And if you have initramfs, you've
> > just made it three times as hard to lay down Runit or Epoch or s6
> > or Suckless Init plus daemontools-encore plus Littkit.
> >
> > We all have to pick our own battles, and I'm not sure how much
> > effort I'd make to roll back the merge. It may indeed be a good
> > thing that only 3 changes are required to patch up Devuan for the
> > merge. But make no mistake about it: regardless of its initial
> > motivation, today the merge's primary beneficiaries are Red Hat and
> > their proxies, Freedesktop.org and Lennart Poettering.
> >
> > SteveT
> >  
> 
>  Sorry Steve but I think you are making some confusion.
> 
>  Before initramfs, there was initrd for the same major purpose:
> to load the necessary device driver to operate the hard disk drive. 
> initramfs is just more clever than initrd. The kernel developpers,
> IIRC, have developped their own set of applications for use in the 
> initrsmfs/initrd.
> 
>  Busybox OTH was not developped for initramfs at all, and Rob 
> Landley was only one of many developpers of Busybox (he's now 
> developping his own alternative). The fact is that Busybox has 
> superseeded anything else in the initramfs because it contains a
> whole Unix base system in a very small program which doesn't even
> need a dynamic library.
> 
>  I doubt Rob Landley had Systemd in mind when he advocated to
> merge /bin and /usr/bin. As a matter of fact Busybox installs its
> symlinks in /bin, /usr/bin, /sbin and /usr/sbin by default.
> 
>  Didier

Hi Didier,

Everything you say above is true, and none of it contradicts what I
originally said.

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list

Re: [DNG] FW: support for merged /usr in Debian

[Clarke Sideroad]

On 01/01/2016 03:06 AM, Daniel Reurich wrote:
> So the potteringisation continues...
>
> Are we going to allow this sort of behaviour into Devuan??
>

I have no say in the matter, but I do feel free to express my opinion
here.  (-:

Devuan _is_, at least at this point, "Debian without systemd", and I
think that is what people like myself are looking for.
I see little choice but to make the merged bin option available, after
all this is all about choice,  but for gosh sakes it should not be the
default.

IMHO it only really makes sense if you are dealing only with end of the
network chain UEFI boxes running primarily as desktop boxes using
systemd or similar as init.

Linux Desktop PC's own < 1.5% desktops last time I looked, in itself a
recently diminishing market that may or may not have stabilized yet.
Linux does own most peoples eyeballs, but that is due to Android not the
"Desktop".
Linux does own most of the World's servers.

Debian runs on a large proportions of the world's servers and this use
makes up the majority of Debian installs.
I cannot see the merging of /bin into /usr/bin being the logical choice
for default and definitely not the only option, but then again I didn't
think they would swallow the systemd poison pill either.

Let's hope the tip of the tail does not continue to wag the dog.

Clarke





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

Re: [DNG] FW: support for merged /usr in Debian

[Micky Del Favero]

Daniel Reurich  writes:

> No, rather freedesktop.org and Poettering are largely synonomous.
> Most of what is proposed there lately is mostly either from Poettering
> or his minions and a lot of what they propose is crap at best and
> destructive to the non-systemd ecosystem at worst.

ok, but "a lot of" is not all, so some ideas can be good and it's stupid
not take them.

> Devuan will continue to use an initramfs as a default is that is the
> only sane approach that provides broad support for most use cases.
> But of course we will support users being able to have the choice to
> build there own initramfs free system too.  They just have to build
> the tooling needed for that approach as packages for devuan.

I agree with it

Ciao, Micky
-- 
The sysadmin has all the answers, expecially "No"
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FW: support for merged /usr in Debian

[Steve Litt]

On Fri, 01 Jan 2016 21:47:57 +0100
Micky Del Favero  wrote:

> Steve Litt  writes:
> 
> > This *is* poetterization, regardless of what Sun or anyone else did
> > before. It's supported by Freedesktop.org, and I think everyone here
> > can agree that anything Freedesktop supports is anti-init choice,
> > anti-simplicity, anti-modularity, and pro-systemd.  
> 
> So anything freedesktop.org supports is a bad idea a priori only
> because freedesktop.org supports systemd even if the same idea
> somebody else has years ago before systemd?

Yes. That would be my first presumption, and it would take a heck of a
lot of proof to convince me otherwise. Judging Freedesktop.Org by
several years of nearly consistent behavior in complexifying software,
I'd say a reasonable person would agree with me.

> For me this is a religion war drives by the same forma mentis of
> poettering's: "#notabug #wontfix because it works for me".
> 
> > Hey, I'll be the first to admit that sometimes you need an
> > initramfs. Maybe you have LUKS plus LVM plus software raid. Merge
> > or not, you'll need to compile yourself one heck of a kernel to
> > avoid needing initramfs. But for the very prevalent use case of
> > Ext4, no raid, no LVM, no LUKS, no silly merge, and a few
> > partitions, initramfs is as  
> 
> Againg you're acting as poettering: if I've a system like yours with
> ext4, without any raid or lvm or luks I can boot my system without
> initramfs, if I have a different setup I'm a heretic man to be
> converted.

Who, an ad homonym followed by a misstatement of my words. Read the
paragraph you're responding to: I said *a lot* of people could benefit
from no initramfs, not *everyone* could benefit from it. It's that
nagging little choice thing again: I'd like the user to have a choice,
but the merge makes such choice almost impossible.

> 
> Will Devuan become the universal operating system that Debian pre
> systemd was or it'll only be the opposite of Debian? 
> 
> All my servers disks are formatted with xfs, on a lvm lv over raid
> volume, all my computers disks are formatted xfs, on some computer I
> also have luks volumes.
> 
> I can recompile the kernel so all needed modules are static compiled
> in kernel, and all users that want a different setup than ext4 without
> raid, lvm, luks or whatever, is it really what we want forcing users
> to recompile kernels on a machine like yours to be able to boot their
> boxes only because you don't like initramfs?

Read my words again. I did not call for the banishment of initramfs
from Devuan.

> 
> Maybe merging /bin in /usr/bin isn't a good idea, maybe it's, I cannot
> see any problem merging /bin in /usr/bin, Solaris made it many yars
> ago and it hasn't systemd and overall it runs without problem due to
> merging, I also think that using initramfs is possible also having
> separate direcroty for /usr and /usr/bin, as it's now.
> 
> > Initramfs does have one big benefit for the Poetterists: It
> > provides a dark, safe place for them to start up their
> > megacomplexities and call it magic. Oh, there are tools with which
> > you can periscope into initramfs, but have you ever really looked
> > at everything in an initramfs? It's a jungle in there. Just right
> > for the Poetterists to incubate their plague.  
> 
> years ago i've built a cluster of diskless servers that network booted
> using a initramfs filesystem, it's not so obscure, I admit it wasn't
> trivial to made the initramfs, but was simpler than you can think.

None of which contradicts the paragraph to which you're responding. And
I'm pretty sure your initramfs, which if I read right you made
yourself, was *a lot* simpler than the initramfs systems that come with
systemd encumbered distros.

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FW: support for merged /usr in Debian

[Steve Litt]

On Fri, 01 Jan 2016 23:32:40 +0100
Micky Del Favero  wrote:

> Daniel Reurich  writes:
> 
> > No, rather freedesktop.org and Poettering are largely synonomous.
> > Most of what is proposed there lately is mostly either from
> > Poettering or his minions and a lot of what they propose is crap at
> > best and destructive to the non-systemd ecosystem at worst.  
> 
> ok, but "a lot of" is not all, so some ideas can be good and it's
> stupid not take them.
> 
> > Devuan will continue to use an initramfs as a default is that is the
> > only sane approach that provides broad support for most use cases.
> > But of course we will support users being able to have the choice to
> > build there own initramfs free system too.  They just have to build
> > the tooling needed for that approach as packages for devuan.  
> 
> I agree with it

And I'd be delighted with the ability to go initramfs-free, on my
simpler pure ext4 systems.

Thanks,

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] FW: support for merged /usr in Debian

[Daniel Reurich]

So the potteringisation continues...

Are we going to allow this sort of behaviour into Devuan??

Daniel


 Forwarded Message 
Subject: support for merged /usr in Debian
Resent-Date: Thu, 31 Dec 2015 00:52:09 + (UTC)
Resent-From: debian-de...@lists.debian.org
Date: Thu, 31 Dec 2015 01:51:45 +0100
From: Marco d'Itri 
To: debian-de...@lists.debian.org

We have a reasonably tested usrmerge package which can be used to
convert on the fly a system to merged /usr, and the good news is that
there are only three packages which need to be fixed to work on a merged
/usr system.

Thanks to my conversion program in usrmerge there is no need for a flag
day, archive rebuilds or similar complexity and we can even continue to
support unmerged systems.

I welcome your comments, but if you have any questions then please read
the FAQ first:
https://wiki.debian.org/UsrMerge
https://anonscm.debian.org/cgit/users/md/usrmerge.git/plain/debian/README.Debian

If you want to help then please have a look at the open bugs linked on
wiki.d.o about lintian and policy work.

-- 
ciao,
Marco


-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722





signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Ummmm, no

[John Rigg]

On Thu, Dec 31, 2015 at 05:26:01PM -0600, Nate Bargmann wrote:
> * On 2015 31 Dec 14:53 -0600, Miles Fidelman wrote:
> 
> > Can you say "kdbus?"
> 
> That doesn't worry me much at this stage as unlike at the higher layers
> where SD support seems to result in support for certain other APIs being
> removed, the kernel has gained all sorts of features over the years that
> are either compile time options or modules.  Given Linus' track record,
> I don't see kdus forcing other RPC code to be removed.  Do you?

I would hope not, or at least that it would be conditional on kdbus config
option being set.

Note that some of the systemd devs have started work on bus1 (their own
replacement for kdbus). Happy New Year!

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

Re: [DNG] Ian Murdock

[aitor_czr]

Hi Emiliano,

On 12/31/2015 07:05 PM, Emiliano Marini  wrote:

Please excuse me, I know many of you can see this like a good tribute for
Ian, but naming "Ian" to the first Devuan stable release could sound like
using his name for the cause, at least for some evil-minded people.


Nobody proposed naming "Ian" to the first stable release. I repeat: 
debian lenny was dedicated to Thiamo Seufer.


Evil-minded? I don't put myself in their shoes.

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

Re: [DNG] Ian Murdock

[KatolaZ]

On Thu, Dec 31, 2015 at 12:21:13PM -0300, Emiliano Marini wrote:
> Please excuse me, I know many of you can see this like a good tribute for
> Ian, but naming "Ian" to the first Devuan stable release could sound like
> using his name for the cause, at least for some evil-minded people.


Maybe my comment was misinterpreted, but by "dedication" I simply
meant a short sentence in the Release Notes saying "This version of
Devuan is dedicated to the memory of Ian Murdock", not changing the
name of the Release to "Ian"...

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

Re: [DNG] FW: support for merged /usr in Debian

[Micky Del Favero]

Daniel Reurich  writes:

> So the potteringisation continues...

If I remember well Solaris has /bin linked to /usr/bin since many years,
so linking /bin to /usr/bin is not a poetteringisation, or almost it's
not an original idea of poettering.

Ciao, Micky
-- 
The sysadmin has all the answers, expecially "No"
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] FW: support for merged /usr in Debian

[Didier Kryn]

Le 01/01/2016 18:07, Steve Litt a écrit :

On Fri, 01 Jan 2016 15:45:49 +0100
Micky Del Favero  wrote:


Daniel Reurich  writes:


So the potteringisation continues...

If I remember well Solaris has /bin linked to /usr/bin since many
years, so linking /bin to /usr/bin is not a poetteringisation, or
almost it's not an original idea of poettering.

Ciao, Micky

Well, OK, if we're really going to discuss this...

This *is* poetterization, regardless of what Sun or anyone else did
before. It's supported by Freedesktop.org, and I think everyone here can
agree that anything Freedesktop supports is anti-init choice,
anti-simplicity, anti-modularity, and pro-systemd.

http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Those of you who have tried to lay down an alternate init system, to
replace systemd, without the aid of a package manager, will probably
agree with me that the toughest obstacle isn't udev, it isn't dbus,
it's initramfs. I looked up the word "black box" in the dictionary last
night, and they had a picture of initramfs.

Hey, I'll be the first to admit that sometimes you need an initramfs.
Maybe you have LUKS plus LVM plus software raid. Merge or not, you'll
need to compile yourself one heck of a kernel to avoid needing
initramfs. But for the very prevalent use case of Ext4, no raid, no
LVM, no LUKS, no silly merge, and a few partitions, initramfs is as
useful as udders on a snake. I mean seriously, in such a use case, you
forego initramfs: boot to the root partition, run /sbin/mount -a, and
bang, you have all resources available to you. But nooo.

Initramfs does have one big benefit for the Poetterists: It provides a
dark, safe place for them to start up their megacomplexities and call
it magic. Oh, there are tools with which you can periscope into
initramfs, but have you ever really looked at everything in an
initramfs? It's a jungle in there. Just right for the Poetterists to
incubate their plague.

Now, the Freedesktop.Org to which I referred earlier in this email has
a link to the following Rob Landley page explaining what they call the
"historical reasons" for separate directories:
jitsi_2.8.5426-1_amd64.deb
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Note that Landley's #1 reason for merging is the existance of
initramfs. Now I'm not stupid enough to call the author of Busybox a
Poetterist. He wrote this in 2010, before anyone really knew the
Napoleonistic aspirations of systemd, back in the days when a complex
and opaque "early boot" wasn't a big deal.

But now it's 5 years later, and that early boot black box is exactly
where the Poetterists fester most virulently.

In summary, if you accept the merge and /usr on a separate partition,
you need initramfs. And if you have initramfs, you've just made it
three times as hard to lay down Runit or Epoch or s6 or Suckless Init
plus daemontools-encore plus Littkit.

We all have to pick our own battles, and I'm not sure how much effort
I'd make to roll back the merge. It may indeed be a good thing that
only 3 changes are required to patch up Devuan for the merge. But make
no mistake about it: regardless of its initial motivation, today the
merge's primary beneficiaries are Red Hat and their proxies,
Freedesktop.org and Lennart Poettering.

SteveT



Sorry Steve but I think you are making some confusion.

Before initramfs, there was initrd for the same major purpose: to 
load the necessary device driver to operate the hard disk drive. 
initramfs is just more clever than initrd. The kernel developpers, IIRC, 
have developped their own set of applications for use in the 
initrsmfs/initrd.


Busybox OTH was not developped for initramfs at all, and Rob 
Landley was only one of many developpers of Busybox (he's now 
developping his own alternative). The fact is that Busybox has 
superseeded anything else in the initramfs because it contains a whole 
Unix base system in a very small program which doesn't even need a 
dynamic library.


I doubt Rob Landley had Systemd in mind when he advocated to merge 
/bin and /usr/bin. As a matter of fact Busybox installs its symlinks in 
/bin, /usr/bin, /sbin and /usr/sbin by default.


Didier



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

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 01 Jan 2016 18:18:38 +
Rainer Weikusat  wrote:

> For a real deployment, this is usually just humbug and can be replaced
> with a kernel containing the drivers necessary for mounting a root
> filesystem.

Plus the drivers for various hardware like cciss devices, just having
ext4 built in is not enough. Wouldn't it be better to have a simple
initramfs with just the apropiate modules for the hardware? Which is
e.g. a copy from /lib/modules//initrd/ where modules reside
that are needed for a root fs to be mounted.

R.

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

richard lucassen  writes:
> Rainer Weikusat  wrote:
>
>> For a real deployment, this is usually just humbug and can be replaced
>> with a kernel containing the drivers necessary for mounting a root
>> filesystem.
>
> Plus the drivers for various hardware like cciss devices, just having
> ext4 built in is not enough. Wouldn't it be better to have a simple
> initramfs with just the apropiate modules for the hardware?

No computer I've either been using privately or professionally ever
suddenly grew a new motherboard (simplification) overnight. Hence,
they're all running kernels with the drivers and filesystems necessary
for booting compiled in.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev

[richard lucassen]

On Fri, 1 Jan 2016 15:28:45 +0100
richard lucassen  wrote:

Forget it. I overlooked the "readme" tab ;-)

> Hello list,
> 
> Is vdev already available somewhere as a package in ascii?
> 
> # apt-get install vdev
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> E: Unable to locate package vdev
> 
> Or do I need to get it from git?
> 
> # cat /etc/apt/sources.list
> deb http://packages.devuan.org/devuan ascii main non-free contrib
> deb http://packages.devuan.org/devuan ascii-updates main non-free
> contrib deb http://packages.devuan.org/merged ascii main non-free
> contrib deb http://packages.devuan.org/merged ascii-updates main
> non-free contrib
> 
> R.
> 


-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 01 Jan 2016 18:42:08 +
Rainer Weikusat  wrote:

> > Plus the drivers for various hardware like cciss devices, just
> > having ext4 built in is not enough. Wouldn't it be better to have a
> > simple initramfs with just the apropiate modules for the hardware?
> 
> No computer I've either been using privately or professionally ever
> suddenly grew a new motherboard (simplification) overnight. Hence,
> they're all running kernels with the drivers and filesystems necessary
> for booting compiled in.

Of course, but I presume that we're talking about a kernel that will be
distributed by Devuan. If you build in hardware drivers for all
different types of hardware, the kernel gets somewhat big IMHO ;-)

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[John Rigg]

On Fri, Jan 01, 2016 at 06:32:34PM +, Rainer Weikusat wrote:
> John Rigg  writes:
> > On Fri, Jan 01, 2016 at 12:26:41PM -0500, Steve Litt wrote:
> >> If / is formatted ext4, it can be mounted directly by a kernel with ext4
> >> drivers, no initramfs needed.
> >
> > Wasn't the original reason for having an initrd that the boot loader,
> > probably LILO at the time, couldn't handle a kernel image above a
> > certain size? (My recollection could be faulty here, so corrections
> > welcome).
> 
> Oh wow. That got twisted :-). LILO loads a kernel image via BIOS calls
> and "10,000 years ago" (ie, I've encountered this problem once, on my
> very first Linux install, RH3.0.3, and then "nevermore" despite I've
> been using LILO all the time), the BIOS couldn't load anything beyond
> "the 1024 cylinder boundary" (504M). Hence, a kernel supposed to be
> loaded by LILO had to be located in the first 504M of a disk. This
> becomes a problem when dual-booting similarly ancient "other PC OSes"
> (in my case, OS/2 Warp 4) which insist on residing on the first primary
> partition.

The 1024 cylinder boundary was why a separate /boot partition at the start
of the disc became common, but still doesn't explain why an initrd.img
became necessary. I used to know this stuff but it was a long time ago :-)

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

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 1 Jan 2016 18:46:05 +
John Rigg  wrote:

> The 1024 cylinder boundary was why a separate /boot partition at the
> start of the disc became common, but still doesn't explain why an
> initrd.img became necessary. I used to know this stuff but it was a
> long time ago :-)

And after all I would certainly not give up a seperate /boot fs. A
separate /boot fs is very handy when running multi Linux system sharing
the same /boot (e.g. in my case, the lilo.conf is there and is
symlinked from all /etc/ directories)

I have 2 Devuan instances on two partitions. When I fsck up
the Devuan running on /dev/sda5 I can always boot into the working one
on /dev/sda3 and correct the mistakes I made on sda5

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Rainer Weikusat]

richard lucassen  writes:
> Rainer Weikusat  wrote:
>> > Plus the drivers for various hardware like cciss devices, just
>> > having ext4 built in is not enough. Wouldn't it be better to have a
>> > simple initramfs with just the apropiate modules for the hardware?
>> 
>> No computer I've either been using privately or professionally ever
>> suddenly grew a new motherboard (simplification) overnight. Hence,
>> they're all running kernels with the drivers and filesystems necessary
>> for booting compiled in.
>
> Of course, but I presume that we're talking about a kernel that will be
> distributed by Devuan. If you build in hardware drivers for all
> different types of hardware, the kernel gets somewhat big IMHO ;-)

Some signals crossed here. I was trying to explain that "a distribution"
has to use initrd/ initramfs because of problems specific to
distribution kernels but that individual users don't have to use this
mechanism if they don't want to because they can just compile a kernel
which will work with their hardware (which is usually rather static).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[John Rigg]

On Fri, Jan 01, 2016 at 08:02:42PM +0100, richard lucassen wrote:
> And after all I would certainly not give up a seperate /boot fs. A
> separate /boot fs is very handy when running multi Linux system sharing
> the same /boot (e.g. in my case, the lilo.conf is there and is
> symlinked from all /etc/ directories)
> 
> I have 2 Devuan instances on two partitions. When I fsck up
> the Devuan running on /dev/sda5 I can always boot into the working one
> on /dev/sda3 and correct the mistakes I made on sda5

I've used a similar setup in the past, with a development system on
one partition and a standard system on another. It's another reason why
I like to keep /boot in a separate partition.

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

Re: [DNG] Giving Devuan sans-initramfs capabilities

[richard lucassen]

On Fri, 01 Jan 2016 19:05:24 +
Rainer Weikusat  wrote:

> > Of course, but I presume that we're talking about a kernel that
> > will be distributed by Devuan. If you build in hardware drivers for
> > all different types of hardware, the kernel gets somewhat big
> > IMHO ;-)
> 
> Some signals crossed here. I was trying to explain that "a
> distribution" has to use initrd/ initramfs because of problems
> specific to distribution kernels but that individual users don't have
> to use this mechanism if they don't want to because they can just
> compile a kernel which will work with their hardware (which is
> usually rather static).

Ok, I think we agree. But as OP said: it would be very nice to get rid
of initramfs. But for a distribution kernel this would be almost
undoable. So what about the idea to just have an initrd containing all
necessary modules for mounting / ? The rest can be loaded once the / fs
has been mounted.

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+--+
| Richard Lucassen, Utrecht|
+--+
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Giving Devuan sans-initramfs capabilities

[Didier Kryn]

Le 01/01/2016 20:05, Rainer Weikusat a écrit :

richard lucassen  writes:

Rainer Weikusat  wrote:

Plus the drivers for various hardware like cciss devices, just
having ext4 built in is not enough. Wouldn't it be better to have a
simple initramfs with just the apropiate modules for the hardware?

No computer I've either been using privately or professionally ever
suddenly grew a new motherboard (simplification) overnight. Hence,
they're all running kernels with the drivers and filesystems necessary
for booting compiled in.

Of course, but I presume that we're talking about a kernel that will be
distributed by Devuan. If you build in hardware drivers for all
different types of hardware, the kernel gets somewhat big IMHO ;-)

Some signals crossed here. I was trying to explain that "a distribution"
has to use initrd/ initramfs because of problems specific to
distribution kernels but that individual users don't have to use this
mechanism if they don't want to because they can just compile a kernel
which will work with their hardware (which is usually rather static).



There might be an optional kernel featuring sata, scsi and a few 
popular filesystems. That would match the vast majority of cases.



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