Re: [DNG] FW: support for merged /usr in Debian
Le 04/01/2016 07:22, Steve Litt a écrit : If you didn't merge /lib and /usr/lib, you could load them from /lib once the root partition was mounted. This was my entire point. OK. I think I got it. Sorry, I was slow. So this is the case: - No initramfs, direct boot to the final rootfs (meaning disk drivers and filesystem built in the kernel), - /usr is on a partition per se, - the file-system of /usr is not the same as / (eg jffs2 for / and ext4 for /usr) - the file-system of /usr is not built-in (eg only jffs2 built-in). Then I agree that startup is impossible if the modules are under /usr. However, cumulating all these condidions is a corner case. And not all these conditions are imposed from outside; most of them are decided by the person who makes the install. Having /usr in a partiton different of / made sense in the time of unsafe filesystem, because there was more chance to corrupt /usr than /. But this is the past now. I've watched a hundredth of brutal power down on servers with reiserfs and btrfs filesystems, and zero filesystem corruption after I abandonned ext2 ~7 years ago. I confess I still use to mount /usr on a partition per se, but I think it has become just a habit which makes no sense anymore and I'm going to stop it. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On Mon, Jan 04, 2016 at 02:57:58AM -0500, Steve Litt wrote: [cut] > > Thanks Joel, > > With my particular skillset, I'd envision my involvement to be more of > documentation somewhat like the Manjaro Experiments > (http://www.troubleshooters.com/linux/init/manjaro_experiments.htm). > With a description of how to set the thing up, others would try it, and > if there's demand, somebody would do the magic necessary to bring it > into the package manager. > Steve, there is really no magic skill involved. By using kernel-package the "skills" needed to do what you mention are just those needed to compile a standard kernel + invoking make-kpkg. There is also a relatively old howto here: http://newbiedoc.sourceforge.net/system/kernel-pkg.html which might be still enough. 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
[DNG] Devuan Weekly News LX
# Devuan News Issue LX __Volume 03, Week 1, Devuan Week 60__ Released 12016/1/04 https://git.devuan.org/devuan-editors/devuan-news/wikis/past-issues/volume-03/issue-060 ## Editorial Happy new year from the Devuan news team! In case you wondered, yes Devuan is alive and kicking. Devuan Weekly News hasn't released a single issue since last June. We're very sorry about that. Did you miss it? [Tell us!][feedback] Last year there was a lot of community effort put into making Devuan and the user experience better, with much cooperation between members of the mailing list. This includes new software for use in Devuan, documentation, and the start of packaging for vdev. Aside from the growing strength of the community, we have seen significant progress towards init freedom in Devuan and the approaching beta release. Important init freedom issues have been solved, and security issues will soon come into focus with an eye on the beta release for critical security updates. We are calling for volunteers on this, so feel free to discuss this on the mailing list. This year will be the year of init freedom, cooperation and community. We hope you will join us in celebrating freedom and justice! -- @dev1fanboy ## Comings and Goings The end of the year 12015 was marked by the unfortunate [death of Debian founder Ian Murdock][IM]. ### Lately in Devuan ### [A discussion about mount-points] [1] Steve Litt asked about the preferred behaviour for an auto-mounter program he is writing in relation to his Python presentation at GoLUG, and the discussion that followed turns out to be instructive for managing mount points. Teodoro Santoni's comments provide [useful tips about UUID's][2], Arnt Karlsen talked about the [purpose of the /media directory][3] and Adam Borowski expanded on this by explaining the [security implications behind the mount point structures][4]. ### [APT pinning compatibility is broken][5] Mitt Green mentioned that upstream changes to APT have landed in the Ceres branch of Devuan, resulting in a break of compatibility for APT pinning rules. Jaromil commented that Devuan [does not rely on pinning][6] to protect against the systemd avalanche. Franco Lanza explained that [pinning can be done on the "server side"][7] and the pinning included in the install [devuan-baseconf] is scheduled for removal for the beta. ### [Init freedom is complete in the base install][8] Daniel Reurich recently fixed an issue that would result in systemd-sysv being the default init at install-time in some cases. Whilst problems concerning init freedom are [not yet solved completely][9], this solves the problem of systemd-sysv being required by default for some debootstrap installs and images built using vmdebootstrap. ### [Security advisory discussions] [10] Back in April hellekin [announced the Devuan talk forum][11] which uses discourse to combine documentation with social features and a platform for discussion. Devuan talk users recently received an email notifying them that security advisories may be discussed there once they begin to be published. Shortly after this notification hellekin [proposed a devuan-security group for the gitlab][32] and is calling for volunteers for the security team. ### [Upower is now working and init agnostic][12] Earlier this month Per Eric Rosén asked how it was possible to [use automatic suspend for the mate desktop on Jessie][13]. Adam Borowski replied saying that a [fork of upower is needed because it depends on systemd][14] for power management features. Daniel Reurich (Centurion_Dan) recently fixed this issue and announced on the Devuan development channel that upower is now working correctly for i386 and amd64, and that it has the necessary pm-utils support. This change means that the xfce4 and mate desktops both have power management support that doesn't rely on systemd, and mate is close to being free of systemd dependencies altogether. ### [Vdev packaging is underway] [15] Last month aitor_czr mentioned that he has started packaging [vdev][16], the Devuan supported device manager. Once the packaging process is complete vdev will then be able to enter the experimental branch to be tested in Devuan. ### [Working with recommends and suggests][17] In a post started by Emiliano Marini about [nmap dependencies][18] fsmithred provided some useful information for working with dependencies, suggests and recommends. Simon Wise built upon this by providing some [information about APT preferences][19] and [referred to the apt-cache manual][20] for further reading. ## New projects for Devuan ### [Devuan migration and minimalism wiki] [21] Dev1fanboy posted a [quick start guide to Devuan migration][22], showing how to migrate to Devuan and configure the install to be more lean. He has since started a wiki project which has received a number of contributions from others, including a [German translation][23] from a contributor who
Re: [DNG] FW: support for merged /usr in Debian
Micky Del Favero writes:
> 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.
Sun/ Oracle don't do Linux development (well, Oracle does, but
strcmp("Solaris", "Linux") != 0). The reason for forcing people to have
'all of /usr' available as soon as / is mounted is because "certain
people" consider it Extremely Good Practice[patent pending] to hardcode
/usr-paths in their C code and such programs break in case someone tries
to run them when /usr isn't mounted.
That was the gut behind the original "separate /usr is broken" aka "my
code is broken because - while it works on my laptop - it may fail to
work elsewhere, depending on the physical layout of the filesystem. But
That's Not How III SEEE ITTT "
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
[DISCLAIMER: I'm using Devuan testing (ascii), thus my comments might not be apply to other versions, jessie in particular! (Which is BTW one reason I try to keep silent on DNG, to not disturb the jessie release process. But since no-one has replied to this post so far ...] On Sun, 3 Jan 2016 17:52:48 + (UTC), Go Linux wrote: > Why are you merging the debian, backports and dmo repos? Is there a way to > separate them? I have rarely used backports and always downloaded what I > need from dmo when I first install and then disable it. dmo can really break > things if you're not careful. I could only speculate about the reasons why, but let me state that one-shot pulling packets from a particular source you thereafter disable completely seems a bit odd to me. How do you receive updates and security fixes? (Note: I, for one, am so far fine with having the bpo and dmo repos merged, since I have been using those for quite some time, but mileage varies vastly, as we all know.) > Avidemux is in the dmo repos. The new 2.6* qt only version leaves a lot to > be desired - a very long story that took several weeks to figure out - so I > took a chance and installed 2.5.6 Gtk from wheezy. Thankfully it works and I > have locked the version. Now is the time that I would want to disable the > dmo repo and not have to worry about newer versions of dependencies mucking > things up. Is there a way to do that with the merged repos? Or will I just > have to be extra vigilant every time there are updates? If I am not completely mistaken, there is no Avidemux package in the official Debian repositories, and there never has been. While I can well understand your stance on the 2.5.* --> 2.6.* Avidemux changes, there is not much one can do, except finding someone capable and willing to maintain the old GTK version (or even do it yourself, if that's an option). OTOH, if you disable deb-multimedia, you get no Avidemux at all. While that's one possible solution, it is presumably not the one you intended. Bottom line: Avidemux GTK is dead (unfortunately, IMHO) and there will come a time when it will prove near to impossible to keep its corpse upright with a few sticks (read: library hacks and the like) while trying to keep away the flies. I decided to let go and let it R.I.P. However, in case you are dead set on completely disabling the dmo repo, you could probably make do with a bit of apt-pinning packages with the "-dmo*" version suffix. Yes, it's an ugly non-intuitive hack, and, even assuming it works as expected, it might not result in what you intended. One more note: I have no evidence, it's really nothing more than just a gut feeling, but I expect less breakage to occur WRT dmo packages in the foreseeable future, since Debian returned to distributing ffmpeg instead of the libav fork (They did, didn't they?), and I am under the impression that a lot of the breakage was due to mismatches between those two. Just my 2 hundredth of your favorite currency. Best regards Irrwahn ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
Le 04/01/2016 12:29, chill...@use.startmail.com a écrit : # Devuan News Issue LX __Volume 03, Week 1, Devuan Week 60__ Released 12016/1/04 https://git.devuan.org/devuan-editors/devuan-news/wikis/past-issues/volume-03/issue-060 ## Editorial Happy new year from the Devuan news team! In case you wondered, yes Devuan is alive and kicking. Devuan Weekly News hasn't released a single issue since last June. We're very sorry about that. Did you miss it? [Tell us!][feedback] Happy New year to the team of Devuan Weekly News. Yes we missed you. Wondered if you were discouraged by the huge amount of off-topic threads... Aside from the growing strength of the community, we have seen significant progress towards init freedom in Devuan and the approaching beta release. Important init freedom issues have been solved, and security issues will soon come into focus with an eye on the beta release for critical security updates. We are calling for volunteers on this, so feel free to discuss this on the mailing list. We are discovering day after day that "init freedom" is about the emerged part of the iceberg. Debian still pretends to offer init freedom. What is under the sea level is a whole monolithic operating system absorbing all critical Linux subsystems like a black hole. Therefore escaping this monster means much more than init freedom, it is something like keeping a free Linux/Gnu OS. It makes more sense every day that RedHat and Debian should rename their OS Systemd/Linux in place of Gnu/Linux. It should make sense to them as well, but I'm afraid they deny the reality. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
On Mon, Jan 04, 2016 at 02:43:57PM +0100, Didier Kryn wrote: > ... > We are discovering day after day that "init freedom" is about > the emerged part of the iceberg. Debian still pretends to offer init > freedom. What is under the sea level is a whole monolithic operating > system absorbing all critical Linux subsystems like a black hole. > Therefore escaping this monster means much more than init freedom, > it is something like keeping a free Linux/Gnu OS. Didier, as a lurker, can I ask what elements besides systemd and udev do you think define this black hole? Is there a consensus over this? Haines Brown ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On 05/01/16 00:31, Irrwahn wrote: On Sun, 3 Jan 2016 17:52:48 + (UTC), Go Linux wrote: Why are you merging the debian, backports and dmo repos? Is there a way to separate them? I have rarely used backports and always downloaded what I need from dmo when I first install and then disable it. dmo can really break things if you're not careful. ... (Note: I, for one, am so far fine with having the bpo and dmo repos merged, since I have been using those for quite some time, but mileage varies vastly, as we all know.) ... One more note: I have no evidence, it's really nothing more than just a gut feeling, but I expect less breakage to occur WRT dmo packages in the foreseeable future, since Debian returned to distributing ffmpeg instead of the libav fork (They did, didn't they?), and I am under the impression that a lot of the breakage was due to mismatches between those two. I am not familiar with recent compatibility, I have not updated any audio workstations for some time, they remain as is. working and never updated. But there has been a sad and difficult history of incompatibilities and sudden breakages using dmo when dmo library updates break non-dmo audio apps which have been built against debian libraries. The dmo libraries did not match the versions in debian, and this includes both the time before libav and since. ffmeg did not have a regular release system, dmo built more frequently and against more recent snapshots than the ones in debian. If you only used audio from dmo it was generally ok, but they do not cover a lot of audio needs. Based on past experience mixing those repositories would definitely exclude using devuan from any audio workstation, or any system which needed other than standard desktop audio needs. It is probably mostly ok with desktop audio. It will certainly mean I cannot use devuan in most machines I look after. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
On Mon, 2016-01-04 at 09:29 -0500, Haines Brown wrote: > On Mon, Jan 04, 2016 at 02:43:57PM +0100, Didier Kryn wrote: > > ... > > We are discovering day after day that "init freedom" is about > > the emerged part of the iceberg. Debian still pretends to offer init > > freedom. What is under the sea level is a whole monolithic operating > > system absorbing all critical Linux subsystems like a black hole. > > Therefore escaping this monster means much more than init freedom, > > it is something like keeping a free Linux/Gnu OS. > > Didier, as a lurker, can I ask what elements besides systemd and udev do > you think define this black hole? Is there a consensus over this? Now they are also pushing hard for the RH invention UsrMerge, see https://packages.debian.org/sid/main/usrmerge and the discussion on debian- devel. In my opinion the change should be the other way around (as GNU/Hurd tried to do a few years ago): ln -s /usr /, i.e. files in /usr/bin/ and /usr/sbin/ should be moved to /bin/ and /sbin/, respectively. Same for /usr/lib to /lib etc. (of course successively). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On Mon, Jan 04, 2016 at 02:01:32AM -0500, Steve Litt wrote: > > But there's a third option, that could be offered as a non-default > choice: > > 3) Compile ext4 and only the most common hard drive and SSD drivers >into a separate and optional kernel that doesn't call an >initramfs, but merely runs an rc file as an init. That rc file >does nothing but get all the drives mounted and then exec the >normal init (sysvinit). > > Repeating: This would be an option, not the default. It would be > optional, not required. It would work only with ext4 and the very most > common hardware drivers. > > The cost of this would be more work for the Devuan developers. With even more work for the Devuan developers 4) Let the installer build the, depending on what the hardware and file systems being installed actually need. -- hendrik > The > benefits would be: > > 1) Simpler, more transparent startup for setups that qualify. > > 2) Very good educationally, because adding initramfs to the mix really >complicates matters while trying to learn the rudiments of bootup. > > 3) Publicity. AFAIK, Devuan would be the only major distro to offer >this option. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
On 05/01/16 00:43, Didier Kryn wrote: Le 04/01/2016 12:29, chill...@use.startmail.com a écrit : Aside from the growing strength of the community, we have seen significant progress towards init freedom in Devuan and the approaching beta release. Important init freedom issues have been solved, and security issues will soon come into focus with an eye on the beta release for critical security updates. We are calling for volunteers on this, so feel free to discuss this on the mailing list. We are discovering day after day that "init freedom" is about the emerged part of the iceberg. Debian still pretends to offer init freedom. What is under the sea level is a whole monolithic operating system absorbing all critical Linux subsystems like a black hole. Therefore escaping this monster means much more than init freedom, it is something like keeping a free Linux/Gnu OS. It makes more sense every day that RedHat and Debian should rename their OS Systemd/Linux in place of Gnu/Linux. It should make sense to them as well, but I'm afraid they deny the reality. There was a very aggressive push to drop the GNU from the GNU/linux name some time ago, it was fairly successful. But of course android/linux is just as much linux as any other system with linux as the kernel (and because of that I can compile a suitable busybox, put it in the right context and get a really useful tablet). Though certainly it is no *nix. Many other routers, fridges, cars or desktop computers are linux. It is the GNU part that makes one or other of them a *nix, it is that part that is being steadily undone alongside the introduction of systemd. Much more so than OSX (the last time I looked anyway) where its toolchain underneath the GUI is still very unix. Apple and Google have the resources to make a decent effort at a big, unified, locked-down, we-know-what-you-need-just-shut-up-and-consume, GUI dominated system. If I wanted a unix like that I'd use OSX and drop in some of the tools that Apple leave out by default, they do fashion and consistent GUI behaviour much better. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
On Mon, 4 Jan 2016 11:29:34 -, chill...@use.startmail.com wrote in message <7ece505dfe773438d59e85b68f9a7b45.startm...@www.startmail.com>: > # Devuan News Issue LX > > __Volume 03, Week 1, Devuan Week 60__ > > Released 12016/1/04 > > https://git.devuan.org/devuan-editors/devuan-news/wikis/past-issues/volume-03/issue-060 > > ## Editorial ... > ### [A discussion about mount-points] [1] > > Steve Litt asked about the preferred behaviour for an auto-mounter > program he is writing in relation to his Python presentation at > GoLUG, and the discussion that followed turns out to be instructive > for managing mount points. Teodoro Santoni's comments provide [useful > tips about UUID's][2], Arnt Karlsen talked about the [purpose of ..er, I did not, I asked the (I believe timely) question "..where did the "/media tradition" come from anyway? " and thenafter it was Stephanie Daugherty who _answered_ my question by talking about said purpose. > the /media directory][3] and Adam Borowski expanded on this by > explaining the [security implications behind the mount point > structures][4]. ... > https://lists.dyne.org/lurker/message/20151225.174135.dd74c0ab.en.html > "Steve Litt asks about prefered auto mounter behaviour" [2]: > https://lists.dyne.org/lurker/message/20151225.235048.e944f0dd.en.html > "Teodoro Santoni talked about labels and UUID's" [3]: > https://lists.dyne.org/lurker/message/20151225.213258.2828fd28.en.html > "Arnt Karlsen talked about the purpose of the /media directory" [4]: > https://lists.dyne.org/lurker/message/20151226.054012.e204f2e8.en.html > "Adam Borowski explained the security implications of /media > and /mnt" [5]: -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
Le 04/01/2016 15:29, Haines Brown a écrit : On Mon, Jan 04, 2016 at 02:43:57PM +0100, Didier Kryn wrote: ... We are discovering day after day that "init freedom" is about the emerged part of the iceberg. Debian still pretends to offer init freedom. What is under the sea level is a whole monolithic operating system absorbing all critical Linux subsystems like a black hole. Therefore escaping this monster means much more than init freedom, it is something like keeping a free Linux/Gnu OS. Didier, as a lurker, can I ask what elements besides systemd and udev do you think define this black hole? Is there a consensus over this? From the beginning, there is also syslog, some integration of the display-manager to have the xwindow server running under user's account. udev and dbus are being absorbed, which was not announced initially There are other things I have read on this list, but I don't remember them... It's much more than an init program. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On Mon, Jan 04, 2016 at 10:10:34AM -0500, Hendrik Boom wrote: > On Mon, Jan 04, 2016 at 02:01:32AM -0500, Steve Litt wrote: > > > > But there's a third option, that could be offered as a non-default > > choice: > > > > 3) Compile ext4 and only the most common hard drive and SSD drivers > >into a separate and optional kernel that doesn't call an > >initramfs, but merely runs an rc file as an init. That rc file > >does nothing but get all the drives mounted and then exec the > >normal init (sysvinit). > > > > Repeating: This would be an option, not the default. It would be > > optional, not required. It would work only with ext4 and the very most > > common hardware drivers. > > > > The cost of this would be more work for the Devuan developers. > > With even more work for the Devuan developers > > 4) Let the installer build the, depending on what the hardware and I meant > 4) Let the installer build the kernel, depending on what the hardware and > file systems being installed actually need. > > -- hendrik > > > The > > benefits would be: > > > > 1) Simpler, more transparent startup for setups that qualify. > > > > 2) Very good educationally, because adding initramfs to the mix really > >complicates matters while trying to learn the rudiments of bootup. > > > > 3) Publicity. AFAIK, Devuan would be the only major distro to offer > >this option. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
Steve Litt writes: [...] > 3) Compile ext4 and only the most common hard drive and SSD drivers >into a separate and optional kernel that doesn't call an >initramfs, but merely runs an rc file as an init. That rc file >does nothing but get all the drives mounted and then exec the >normal init (sysvinit). Your understanding of that is still a little faint: 'Starting userspace' really works by 1) Mount the root filesystem. 2) Start a process running /sbin/init. > Repeating: This would be an option, not the default. It would be > optional, not required. It would work only with ext4 and the very most > common hardware drivers. And what precisely is "a very most common hardware driver"? Do you want to setup a commitee voting on that (regularly, as hardware changes over time)? And what's "a very most common filesystem"? What about other, optional kernel features, eg, I'm running kernels compiled without ASR and with kernel preemption disabled (and I used 250Hz as tick frequency before switching tickless). The sensible way to handle this is really "the distribution ships a kernel which optionally supports everything" (via aggressive modularization) and people who think they want/ need more control over this part of the system can change that as they see fit (by compiling a custom kernel). Insofar someone feels his custom kernel is of more general use than just "run on this machine", the configuration could be shared via internet. It's even failrly easy to share the kernel itself: I posted a script I've been using since 1998 to build kernels for different machines on a dedicated one and for someone who likes "shot from behind trough the chest right into the eye" constructions, there's always kernel-package for creating custom-kernel Debian packages. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
SD now includes a replacement for running ntp/ntpdate to synchronize time so that is being absorbed. It's probably a wash and low on most desktop users list, but one more example of SD becoming your complete middleware system! - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
Le 04/01/2016 16:26, Hendrik Boom a écrit : I meant >4) Let the installer build the kernel, depending on what the hardware and >file systems being installed actually need. Maybe Gentoo does this, although I'm not sure, but the philosophy is very different: they compile everything from source. And it doesn't install as smoothly as Devuan. In Devuan it means something very unusual: the installer must first install gcc, generate a config file and compile the kernel. It is not an easy task to generate a working config for any hardware combination. The resulting kernel package would be local and couldn't undergo upgrades. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On Mon, 2016-01-04 at 16:53 +0100, Didier Kryn wrote: > Le 04/01/2016 16:26, Hendrik Boom a écrit : > > I meant > > > > 4) Let the installer build the kernel, depending on what the hardware > > > > and > > > > file systems being installed actually need. > > Maybe Gentoo does this, although I'm not sure, but the philosophy > is very different: they compile everything from source. And it doesn't > install as smoothly as Devuan. > > In Devuan it means something very unusual: the installer must first > install gcc, generate a config file and compile the kernel. It is not an > easy task to generate a working config for any hardware combination. The > resulting kernel package would be local and couldn't undergo upgrades. Just an idea: Would it be possible to detect the hardware of each computer being installed on and after that install the needed modules? Preferably the modules should not be located on /usr, currently they are under /lib. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
Nate Bargmann writes: > SD now includes a replacement for running ntp/ntpdate to synchronize > time so that is being absorbed. According to information 'from the internet', that's an SNTP client and While a full featured NTP server or -client reaches a very high level of accuracy and avoids abrupt timesteps as much as possible by using different mathematical and statistical methods and smooth clock speed adjustments, SNTP can only be recommended for simple applications, where the requirements for accuracy and reliability are not too demanding. By disregarding drift values and using simplified ways of system clock adjustment methods (often simple time stepping), SNTP archieves only a low quality time synchronization when compared with a full NTP implementation. https://www.meinbergglobal.com/english/faq/faq_37.htm This then (finally!) achieves something certain people have been pushing for for a long time, namely, it renders the 'wallclock' useless for sychronizing operations of distributed systems by turning it into a PRNG (which may randomly jump backward and forward according to the whims of the SNTP implementation). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OT: Desktop recording
On Sun, 03 Jan 2016 05:28:07 -0600, vmlinux wrote in message <13298612-ee2c-461a-856f-964d689dc...@charter.net>: > After reading Steve's post about Statifier I got to thinking; where > is a good desktop recording for Linux ? ..systemd? ;o) ..define "good." ;o) ..aaand, there are standards to measure up against... ;o) http://web.cs.ucdavis.edu/~rogaway/papers/moral-fn.pdf > I used to use Wink[1] but the > guy hasn't put out a Linux update in a long time. > > Anyone have a recommendation for something like RecordMyDesktop[2] > which allows you to insert notes/balloons, pause for user > interaction, and/or mix the video down into different formats? > > [1] http://www.debugmode.com/wink/ > [2] http://recordmydesktop.sourceforge.net/about.php -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
Le 04/01/2016 17:32, Svante Signell a écrit : On Mon, 2016-01-04 at 16:53 +0100, Didier Kryn wrote: Le 04/01/2016 16:26, Hendrik Boom a écrit : I meant 4) Let the installer build the kernel, depending on what the hardware and file systems being installed actually need. Maybe Gentoo does this, although I'm not sure, but the philosophy is very different: they compile everything from source. And it doesn't install as smoothly as Devuan. In Devuan it means something very unusual: the installer must first install gcc, generate a config file and compile the kernel. It is not an easy task to generate a working config for any hardware combination. The resulting kernel package would be local and couldn't undergo upgrades. Just an idea: Would it be possible to detect the hardware of each computer being installed on and after that install the needed modules? Preferably the modules should not be located on /usr, currently they are under /lib. I don't understand the repulsion towards having the modules in /usr/lib. What difference does it make? None, unless you want the three following conditions: no initramfs, /usr being a mountpoint, some drivers and filesystems compiled in the kernel, but missing just the one for /usr. You've got to work pretty hard to fulfill these conditions. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Possible bug of apt-cache show?
On Mon, Jan 04, 2016 at 01:24:02AM +1300, Daniel Reurich wrote: [cut] > Ok.. perhaps this thread explains it: > > https://lists.debian.org/deity/2009/08/msg00073.html > > the gist is, they've been moved to translations even for english... we > don't yet have the translation support in our repo... > > Thanks Daniel! I hadn't noticed it in the last five years, meaning that the whole thing worked quite well overall. Would it be possible to have at least the EN Translations.gz added to our repo? That would be very much appreciated. 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] OT: Desktop recording
At dyne.org we are just setting up an office room for video tutorials and the dedicated computer is running vokoscreen. Worthed mentioning, works well on Devuan! and is packaged, yet the upstream version is more recent http://www.kohaupt-online.de/hp/ ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On Mon, 1/4/16, Irrwahn wrote: Subject: Re: [DNG] Question about the merged repos To: dng@lists.dyne.org Date: Monday, January 4, 2016, 7:31 AM On Sun, 3 Jan 2016 17:52:48 + (UTC), Go Linux wrote: >> > Why are you merging the debian, backports and dmo repos? Is there a way to > separate them? I have rarely used > backports and always downloaded what I > need from dmo when I first install and then disable it. dmo can really > break things if you're not careful. >> > How do you receive updates and security fixes? I generally don't. 'If it works, don't fix it' especially when it comes to complex media stuff. Case in point, I recently upgraded avidemux and dvdstyler for squeeze. Now the 'do not transcode' option is no longer checked by default in dvdstyler. That really sucks and there is no option to down grade. >> > Avidemux is in the dmo repos. The new 2.6* qt only version leaves a lot to > be desired - a very long story that took > several weeks to figure out - so I > took a chance and installed 2.5.6 Gtk from wheezy. Thankfully it works and I > have > locked the version. Now is the time that I would want to disable the > dmo repo and not have to worry about newer > versions of dependencies mucking > things up. Is there a way to do that with the merged repos? Or will I just > have to > be extra vigilant every time there are updates? >> > > If I am not completely mistaken, there is no Avidemux > package in the official Debian repositories, and there > never has been. > This is true. I should have said I downloaded it from wheezy dmo repos. :) > > While I can well understand your stance > on the 2.5.* --> 2.6.* Avidemux changes, there is not > much one can do, except finding someone capable and > willing to maintain the old GTK version (or even do it > yourself, if that's an option). > Or find another video editor (ugh) or just keep wheezy and Jessie working for the duration. At my age it's a question of whether avidemux Gtk will outlast me or I'll outlast it! > > I decided to let go and let it R.I.P. > It was great while it lasted, wasn't it!! It took me days to to find all the deps and build the latest version from their git sources to fix the alsa default lockup (which required commenting out a line in a source file). Once I got it working I realized there was no cross fade in the qt version!! The dev's excuse was 'It's not easy to do with the 2.6 codebase'. How can anyone edit without a crossfade?? > > However, in case you are dead set on completely disabling > the dmo repo, you could probably make do with a bit of > apt-pinning packages with the "-dmo*" version suffix. > Yes, it's an ugly non-intuitive hack, and, even assuming > it works as expected, it might not result in what you > intended. > Probably not worth the effort. > > One more note: I have no evidence, it's really nothing > more than just a gut feeling, but I expect less breakage > to occur WRT dmo packages in the foreseeable future, since > Debian returned to distributing ffmpeg instead of the > libav fork (They did, didn't they?), and I am under the > impression that a lot of the breakage was due to > mismatches between those two. > FWIW. Avidemux builds ffmpeg into the app so doesn't require outside source. dvdstyer OTOH does require external ffmpeg. Thanks for the detailed response. It was helpful if only to confirm what I suspected. At least I'm set for the next couple of years . . . golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX (Errata)
On 01/04/2016 03:07 PM, Arnt Karlsen wrote: >> >> https://git.devuan.org/devuan-editors/devuan-news/wikis/past-issues/volume-03/issue-060 >> >> tips about UUID's][2], Arnt Karlsen talked about the [purpose of > > ..er, I did not, I asked the (I believe timely) question > "..where did the "/media tradition" come from anyway? " > and thenafter it was Stephanie Daugherty who _answered_ > my question by talking about said purpose. > Thank you for this correction, Arnt. It's been corrected on the Web version. == 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] GNOME3 and Co.
Bryan Baldwin wrote: >Gentoo lovers have already been using this patchset to keep GNOME 3 >systemd-less. >It would be great to get an even larger part of the systemd-free community >behind this project. >I'd love to see Devuan GNOME 3 packages :) I think that Gentoo people (and Funtoo) don't experience problems we have, like patches, messed and missed dependencies that change over and over; I mean, their packaging system is simpler. Mitt___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GNOME3 and Co.
Yours truly wrote: >I think that Gentoo people (and Funtoo) don't experience problems we have, like >patches, messed and missed dependencies that change over and over; >I mean, their packaging system is simpler. Most of the time the problem is package maintainers that use horrible dependencies, which causes what we have: incompatible versions (see "merged repos" thread and experience Sid/Unstable/Ceres updates) and systemd conquista. My €0.02 Mitt___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On Mon, 2016-01-04 at 17:43 +0100, Didier Kryn wrote: > Le 04/01/2016 17:32, Svante Signell a écrit : > Just an idea: Would it be possible to detect the hardware of each computer > being installed on and after that install the needed modules? Preferably the > modules should not be located on /usr, currently they are under /lib. > > I don't understand the repulsion towards having the modules in > /usr/lib. What difference does it make? None, unless you want the three > following conditions: no initramfs, /usr being a mountpoint, some > drivers and filesystems compiled in the kernel, but missing just the one > for /usr. You've got to work pretty hard to fulfill these conditions. Well, the important part of my question was: "Would it be possible to detect the hardware of each computer being installed on and after that install the needed modules?" Where the modules are located is very much under discussion here and on debian- devel, see the "support for merged /usr in Debian" thread there. This is another issue that could be discussed elsewhere here. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On Mon, Jan 04, 2016 at 05:32:26PM +0100, Svante Signell wrote: [cut] > > Just an idea: Would it be possible to detect the hardware of each computer > being > installed on and after that install the needed modules? Preferably the modules > should not be located on /usr, currently they are under /lib. Hi Svante, the kernel itself is able to auto-detect the (known) hardware on which it is running, and load the corresponding modules since ever. In principle, if a minimal (and massively modular) kernel is used during installation (as currently happens for Debian/Devuan) a list of modules to be installed can be obtained at install time by a bash one-liner like lsmod | cut -d " " -f 1 | sort However, this will not solve the problem of upgrades. 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] Devuan Weekly News LX
Simon Wise wrote: >There was a very aggressive push to drop the GNU from the GNU/linux name some >time ago, it was fairly successful. But of course android/linux is just as much >linux as any other system with linux as the kernel (and because of that I can >compile a suitable busybox, put it in the right context and get a really useful >tablet). Though certainly it is no *nix. Many other routers, fridges, cars or >desktop computers are linux. It is the GNU part that makes one or other of them >a *nix, it is that part that is being steadily undone alongside the >introduction >of systemd. Much more so than OSX (the last time I looked anyway) where its >toolchain underneath the GUI is still very unix. Hehe, >Android (operating system) >Developer: Google >Written in: C, C++, Java >OS family: Unix-like There's certainly something Unix-ish in Android apart from the kernel; 'tis a Unix filesystem, a shell (mksh) and Unix programmes (what in GNU people call coreutils). OSX is still Unix, and we can compile (pretty much) everything we use now on GNU/Linux on OSX. Think of OpenDarwin with Xfce, or pkgsrc on OSX. What it moves away from Unix is the UI. But the same we can say about Unity, GNOME, Cinnamon and KDE. Mitt___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
Svante Signell writes: > On Mon, 2016-01-04 at 17:43 +0100, Didier Kryn wrote: >> Le 04/01/2016 17:32, Svante Signell a écrit : > >> Just an idea: Would it be possible to detect the hardware of each computer >> being installed on and after that install the needed modules? Preferably the >> modules should not be located on /usr, currently they are under /lib. >> >> I don't understand the repulsion towards having the modules in >> /usr/lib. What difference does it make? None, unless you want the three >> following conditions: no initramfs, /usr being a mountpoint, some >> drivers and filesystems compiled in the kernel, but missing just the one >> for /usr. You've got to work pretty hard to fulfill these conditions. > > Well, the important part of my question was: "Would it be possible to detect > the > hardware of each computer being installed on and after that install the needed > modules?" "Somewhat". The kernel will send uevents for everything it detects (or invoke a modprobe/ hotplug program with this information). But 'the hardware' is not static. Eg, I have an USB printer/scanner that's usually turned off. I installed the OS on my current 'workstation' by connecting the disk to the SATA bus of the old one, copying the system over and the compiling a kernel I considered to be capable of booting the new one. Alternatively, one could also just move a disk to a new machine. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
[Sorry, Golinux, replied to you directly by accident, post was intended to go to the list.] On Mon, 4 Jan 2016 16:53:39 + (UTC), Go Linux wrote: > On Mon, 1/4/16, Irrwahn wrote: >> How do you receive updates and security fixes? > > I generally don't. 'If it works, don't fix it' especially when it comes to > complex media stuff. Fair enough. >> While I can well understand your stance >> on the 2.5.* --> 2.6.* Avidemux changes, there is not >> much one can do, except finding someone capable and >> willing to maintain the old GTK version (or even do it >> yourself, if that's an option). > > Or find another video editor (ugh) Ugh indeed, don't get me even started. That's why I didn't mention that option. :] > or just keep wheezy and Jessie working for the duration. > At my age it's a question of whether avidemux Gtk will outlast me or I'll > outlast it! While certainly no longer a youngster, I wish I could say the same. :> >> I decided to let go and let it R.I.P. > > It was great while it lasted, wasn't it!! It took me days to to find all the > deps and build the latest version from their git sources to fix the alsa > default lockup (which required commenting out a line in a source file). Once > I got it working I realized there was no cross fade in the qt version!! The > dev's excuse was 'It's not easy to do with the 2.6 codebase'. How can anyone > edit without a crossfade?? And that's only one of the great new 2.6 "features". While I understand the motivation to rewrite a thoroughly rotten code base (let's face it, Avidemux never was an extraordinary stable piece of software), I never got my head around them dropping essential features and filters even the most simplistic video editor should provide, and then go and blame the shiny new code base. In my book, that's kind of backwards. > FWIW. Avidemux builds ffmpeg into the app so doesn't require outside source. > dvdstyer OTOH does require external ffmpeg. Oh, great, even more fun! :P This all reminds me how I had to build MPV from source on a regular basis. Luckily, this was an almost trivial task, thanks to the MPV folks. (And, since it carries its own versions of the ffmpeg libraries, gets around a good portion of the usual dependency hell.) > Thanks for the detailed response. It was helpful if only to confirm what I > suspected. At least I'm set for the next couple of years . . . It was nothing. I keep my fingers crossed, may it last as long as you hope for. :) Best regards Irrwahn ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On Tue, 05 Jan 2016 01:22:01 +1100, Simon Wise wrote: > On 05/01/16 00:31, Irrwahn wrote: [ About mixing packages from Debian and Deb-Multimedia. ] [...] > If you only used audio from dmo it was generally ok, but they do not cover a > lot > of audio needs. I guess I have just been lucky then, the last couple years. Phew. > Based on past experience mixing those repositories would definitely exclude > using devuan from any audio workstation, or any system which needed other > than > standard desktop audio needs. It is probably mostly ok with desktop audio. > > It will certainly mean I cannot use devuan in most machines I look after. If this is true, and you are probably not the only one affected, I wonder if maybe Devuan should reconsider merging the dmo repos. For those who want them it's trivial to add to sources.list, much easier then to apt-pin them out of the way if one does not want to use them. Freedom of choice, etc. And in the unlikely case that some multimedia package from dmo gets the systemdisease, there are several possible ways to tackle that, without unconditionally merging the whole dmo repository. Thanks for the heads-up! Best regards Urban ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On Mon, 04 Jan 2016 17:32:26 +0100 Svante Signell wrote: > Just an idea: Would it be possible to detect the hardware of each > computer being installed on and after that install the needed > modules? IIUC, exactly this hardware detection is already happening. Regarding the installation of the initramfs, the installer gives you the choice whether to include "all" or an adapted subset of modules. HTH / correct me if I'm wrong. Regards, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] RFP: Bastille-Linux is a hardening program for linux.
Package: wnpp Severity: wishlist * Package name: bastille-linux Version : 3.0.9 Upstream Author : Jay Beale * URL : http://bastille-linux.sourceforge.net/ * License : (GPL) Programming Lang: (TCL, Perl5) Description : Bastille Linux is a well tested hardening script for *nix The Bastille Hardening program "locks down" an operating system, proactively configuring the system for increased security and decreasing its susceptibility to compromise. Bastille can also assess a system's current state of hardening, granularly reporting on each of the security settings with which it works. Bastille currently supports the Red Hat (Fedora Core, Enterprise, and Numbered/Classic), SUSE, Debian, Gentoo, and Mandrake distributions, along with HP-UX. It also supports Mac OS X. Bastille's focuses on letting the system's user/administrator choose exactly how to harden the operating system. In its default hardening mode, it interactively asks the user questions, explains the topics of those questions, and builds a policy based on the user's answers. It then applies the policy to the system. In its assessment mode, it builds a report intended to teach the user about available security settings as well as inform the user as to which settings have been tightened. http://bastille-linux.sourceforge.net/ http://old-releases.ubuntu.com/ubuntu/pool/universe/b/bastille/ http://old-releases.ubuntu.com/ubuntu/pool/universe/b/bastille/bastille_3.0.9.orig.tar.gz http://old-releases.ubuntu.com/ubuntu/pool/universe/b/bastille/bastille_3.0.9-13_all.deb (Note: use a version of TCL slightly older than what is in Debian7, there was some incompatable update of TCL it seems some time within the Debian7 release (bastille worked fine in early versions, and previous to that in the testing release of Deb7 just before stable, but in late versions of Debian 7 it cannot save its config files because TCL DEEEPPPRREEECIAAATTEE (High Pitched Lennart Chortle) decades working code (even though all TCL scripts are ancient)) (Also note: There is a section of the code in 2 files where the distro is handled, Debian is handled there, perhaps add Devuan (as evrything will be the same) to the list aswell) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
I don't understand the desire to change it at all. We know where the kern modules are now, we've known for over a decade, just leave it as it was. If systemd wasn't, this wouldn't be talked about. Which is why it shouldn't be discussed. Don't let them pull you by the nose. At all. On 2016-01-04 16:43, Didier Kryn wrote: Le 04/01/2016 17:32, Svante Signell a écrit : On Mon, 2016-01-04 at 16:53 +0100, Didier Kryn wrote: Le 04/01/2016 16:26, Hendrik Boom a écrit : I meant 4) Let the installer build the kernel, depending on what the hardware and file systems being installed actually need. Maybe Gentoo does this, although I'm not sure, but the philosophy is very different: they compile everything from source. And it doesn't install as smoothly as Devuan. In Devuan it means something very unusual: the installer must first install gcc, generate a config file and compile the kernel. It is not an easy task to generate a working config for any hardware combination. The resulting kernel package would be local and couldn't undergo upgrades. Just an idea: Would it be possible to detect the hardware of each computer being installed on and after that install the needed modules? Preferably the modules should not be located on /usr, currently they are under /lib. I don't understand the repulsion towards having the modules in /usr/lib. What difference does it make? None, unless you want the three following conditions: no initramfs, /usr being a mountpoint, some drivers and filesystems compiled in the kernel, but missing just the one for /usr. You've got to work pretty hard to fulfill these conditions. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
chaosesquet...@cock.li: > I don't understand the desire to change it at all. And neither do I. Except someone talked about ssl libs. > On 2016-01-04 16:43, Didier Kryn wrote: ... > > I don't understand the repulsion towards having the modules in > > /usr/lib. What difference does it make? None, unless you want the > > three following conditions: no initramfs, /usr being a mountpoint, > > some drivers and filesystems compiled in the kernel, but missing just > > the one for /usr. You've got to work pretty hard to fulfill these > > conditions. If you have a desire to move /lib/modules why don't move it and everything you need to boot to /boot. From what I understand uefi requires some vfat (or ext2 for mbr) boot partition first in disk. Then include ahci (which would handle the majority of not to old sata disk controllers out there) and vfat in the kernel. Mount /boot in your initrd and go from there. /boot can always be mounted read-only unless when changing kernel and boot things. Files in /boot don't need user id's nor unix permissions so vfat is perfectly ok. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
k...@aspodata.se writes: > chaosesquet...@cock.li: >> I don't understand the desire to change it at all. > > And neither do I. > Except someone talked about ssl libs. Someone wrote about some PAM module which would require OpenSSL. No such PAM module currently exists on my system and I don't quite understand why 'PAM modules' would be needed for booting a system, anyway. But udev wants to put its rules files below /usr by default and as far as I know, changing this requires patching the code. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GNOME3 and Co.
On 01/05/2016 06:26 AM, Mitt Green wrote: > Yours truly wrote: > > >I think that Gentoo people (and Funtoo) don't experience problems we > have, like > >patches, messed and missed dependencies that change over and over; > >I mean, their packaging system is simpler. > > Most of the time the problem is package maintainers that use horrible > dependencies, > which causes what we have: incompatible versions (see "merged repos" > thread and > experience Sid/Unstable/Ceres updates) and systemd conquista. > > My €0.02 While portage is simple, the drawback is that each system you build with it is its own snowflake. You'll realize this as soon as you try to distribute artifacts amongst many different systems. The patchset I linked: https://github.com/dantrell/gentoo-project-gnome-without-systemd Does have dependencies on Gentoo's default init system, OpenRC, and some other bits and pieces. But, if there were a desire within Devuan to package GNOME 3, this could be a good place to start. It will at minimum show you where your changes should go in the GNOME 3 codebase. If you hate GNOME, or don't want to try to support code from developers who are deliberately ignoring the systemd-free community, I couldn't blame you ;) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On Mon, 2016-01-04 at 20:43 +, Rainer Weikusat wrote: > k...@aspodata.se writes: > > chaosesquet...@cock.li: > > > I don't understand the desire to change it at all. See UsrMerge discussion on debian-devel. They wan to move most stuff in / to /usr and make it readonly. (The only sensible motivation I've found so far is for NFS, but how many people use that? > > And neither do I. > > Except someone talked about ssl libs. > > But udev wants to put its rules files below /usr by default and as far > as I know, changing this requires patching the code. The more we need to have vdev debianised then! aitor_csr, can I help? What about eudev? ___ 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: > k...@aspodata.se writes: > > chaosesquet...@cock.li: > >> I don't understand the desire to change it at all. > > > > And neither do I. > > Except someone talked about ssl libs. > > Someone wrote about some PAM module which would require OpenSSL. No such > PAM module currently exists on my system and I don't quite understand > why 'PAM modules' would be needed for booting a system, anyway. > > But udev wants to put its rules files below /usr by default and as far > as I know, changing this requires patching the code. Don't use udev so cannot check that. Perhaps time for devuan to switch to vdev, is it ready for prime time ? Why don't udev place its rules close to the kernel modules directory, that would make more sense, or put them under /etc as is the conventional wisdom. But then, /etc-less systems are thought about: http://0pointer.net/blog/projects/stateless.html Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GNOME3 and Co.
Bryan Baldwin wrote: >...does have dependencies on Gentoo's default init >system, OpenRC, and some other bits and >pieces. I don't really understand, why a desktop environment depends on a initialisation system. >But, if there were a desire within Devuan >to package GNOME 3, this could be a good place >to start. It will at minimum >show you where your changes should go in the GNOME 3 codebase. I reckon, the approach is "huh GNOME3? No, not really, hey, you want this? Ok, maybe one day, but not today." >If you hate GNOME, [...] I don't really hate GNOME3, but I still have somewhat a bitter taste of it from my experiences with CentOS 7 in particular and short Fedora sessions; I think it is really an unstable piece of (software ), comparing to my all-time favourite Xfce. Do we really need animations, CSS and JS in a DE, overview mode and huge icons of programmes there? What I strongly dislike is the way it is packaged in Debian. >or don't want to try to >support code from developers >who are deliberately ignoring the systemd-free >community, I couldn't >blame you ;) GNOME3 is by the way a Red Hat product, I reckon, they deliberately push the dependency, so we can face their desire to control the whole Linux world one more time and keep BSDs out of the game (remember Poettering thoughts on Berkleys?). It brings the taste again. My two puint worth and a free (as in beer) tinfoil hat, Mitt___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
Karl Hammar wrote: >But then, /etc-less systems are thought about: >[http://0pointer.net/blog/projects/stateles](http://0pointer.net/blog/projects/stateless.html)s.html PulseAudio motto is "I'll break your audio", Lennartd should be "I'll break your Unix". What's next, I wonder. If they call it "innovations", I'd rather stay in my cave. We will end up with the kernel depending on systemd one day.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GNOME3 and Co.
Am Montag, 4. Januar 2016 schrieb Mitt Green: > I don't really understand, why a desktop environment > depends on a initialisation system. I'm sure M$ has a good answer to this question. And GNOME has a registry, too, which is a very good thing to have, I was told ;-) > GNOME3 is by the way a Red Hat product, > I reckon, they deliberately push the dependency, > so we can face their desire to control the whole > Linux world one more time and keep > BSDs out of the game (remember Poettering > thoughts on Berkleys?). It brings the taste again. BSD will have a systemd-emulator sooner or later, just something like linuxulator now. And if GNOME will be systemd-only and too hard to maintain, then it'll be simply dropped. Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On Mon, 4 Jan 2016 22:13:06 +0100 (CET), k...@aspodata.se wrote in message <20160104211307.20a5d809d...@turkos.aspodata.se>: > Rainer Weikusat: > > k...@aspodata.se writes: > > > chaosesquet...@cock.li: > > >> I don't understand the desire to change it at all. > > > > > > And neither do I. > > > Except someone talked about ssl libs. > > > > Someone wrote about some PAM module which would require OpenSSL. No > > such PAM module currently exists on my system and I don't quite > > understand why 'PAM modules' would be needed for booting a system, > > anyway. > > > > But udev wants to put its rules files below /usr by default and as > > far as I know, changing this requires patching the code. > > Don't use udev so cannot check that. Perhaps time for devuan to > switch to vdev, is it ready for prime time ? > > Why don't udev place its rules close to the kernel modules directory, > that would make more sense, or put them under /etc as is the > conventional wisdom. But then, /etc-less systems are thought about: > > http://0pointer.net/blog/projects/stateless.html ...which is also © Lennart Poettering. Let them systemd guys prove us wrong in the _long_ run. ;o) ..in the short term, I'm pleasantly surprised to see more traffic here in devuan-* than in debian-user. ;oD -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On 04/01/16 06:52, Go Linux wrote: > Why are you merging the debian, backports and dmo repos? Is there a > way to separate them? I have rarely used backports and always > downloaded what I need from dmo when I first install and then disable > it. dmo can really break things if you're not careful. We are currently merging dmo - was mostly done as a test for amprolla. I can ask nextime to remove that if it is causing breakages or other problems. As for locking to specific versions, that *is* what pinning is meant for. Not merging dmo won't prevent an upgrade causing a broken debian version to be pulled in instead. We are NOT merging backports or updates or security updates. These will all be handled as separate repositories. If you want backports (or stable updates) you have to specify them in your /etc/apt/sources.list We'll of course need to document this in our "getting started with Devuan" guide which has yet to be written. Regards, Daniel. -- 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
[DNG] PAM usage (Was: Giving Devuan sans-initramfs capabilities)
Good evening, 2016-01-04 21:43 GMT+01:00, Rainer Weikusat : > k...@aspodata.se writes: >> chaosesquet...@cock.li: >>> I don't understand the desire to change it at all. >> >> And neither do I. >> Except someone talked about ssl libs. > > Someone wrote about some PAM module which would require OpenSSL. No such > PAM module currently exists on my system and I don't quite understand > why 'PAM modules' would be needed for booting a system, anyway. Nothing is impossible and someone may wish to integrate his/her wordpress' login credentials with the computer(s) he/she manage. I recognize it's a stupid example. However: logind, systemd, the MadnessKit family of Kits, break configurations because of byzantine and heterogenous types of login (rfid, TPM, fingerprints, ...), masses of sec data different than "a key for a service" and multi-user access to programs (thirty years of X server and you can run X as root XOR use systemd). Or so it seems. But do any of you find useful to have PAM? Do any of you need single-sign-on, TPM, smart-cards that unlock ttys, integrate kerberos with linux, or the like? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On Mon, 1/4/16, Daniel Reurich wrote: Subject: Re: [DNG] Question about the merged repos To: "Go Linux" , "dng@lists.dyne.org" Date: Monday, January 4, 2016, 4:33 PM On 04/01/16 06:52, Go Linux wrote: > Why are you merging the debian, backports and dmo repos? Is there a > way to separate them? I have rarely used backports and always > downloaded what I need from dmo when I first install and then disable > it. dmo can really break things if you're not careful. We are currently merging dmo - was mostly done as a test for amprolla. I can ask nextime to remove that if it is causing breakages or other problems. As for locking to specific versions, that *is* what pinning is meant for. Not merging dmo won't prevent an upgrade causing a broken debian version to be pulled in instead. We are NOT merging backports or updates or security updates. These will all be handled as separate repositories. If you want backports (or stable updates) you have to specify them in your /etc/apt/sources.list We'll of course need to document this in our "getting started with Devuan" guide which has yet to be written. Regards, Daniel. For my use case, I would prefer to have all the repos separated because it's much easier to manage and for consistency because that is the way that debian has always done it. If a repo is commented out, there is no chance of upgrade breakage. :) Or at least eliminates one avenue for an oops to slip in. I usually only update media software if it starts to fail in some way and then keep my fingers crossed . . . golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On 05/01/16 11:33, Daniel Reurich wrote: > On 04/01/16 06:52, Go Linux wrote: >> Why are you merging the debian, backports and dmo repos? Is there >> a way to separate them? I have rarely used backports and always >> downloaded what I need from dmo when I first install and then >> disable it. dmo can really break things if you're not careful. > > We are currently merging dmo - was mostly done as a test for > amprolla. I can ask nextime to remove that if it is causing breakages > or other problems. > Update: I have raised an issue about no longer merging dmo. There are a bunch of other reasons for removing it as well - but I won't discuss them here. :D -- 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] Giving Devuan sans-initramfs capabilities
Le 04/01/2016 18:33, Svante Signell a écrit : On Mon, 2016-01-04 at 17:43 +0100, Didier Kryn wrote: Le 04/01/2016 17:32, Svante Signell a écrit : Just an idea: Would it be possible to detect the hardware of each computer being installed on and after that install the needed modules? Preferably the modules should not be located on /usr, currently they are under /lib. I don't understand the repulsion towards having the modules in /usr/lib. What difference does it make? None, unless you want the three following conditions: no initramfs, /usr being a mountpoint, some drivers and filesystems compiled in the kernel, but missing just the one for /usr. You've got to work pretty hard to fulfill these conditions. Well, the important part of my question was: "Would it be possible to detect the hardware of each computer being installed on and after that install the needed modules?" Where the modules are located is very much under discussion here and on debian- devel, see the "support for merged /usr in Debian" thread there. This is another issue that could be discussed elsewhere here. There are two places where a driver can be: either statically linked with the kernel, or in a loadable module. In the second case the kernel has some minimal interface to the driver that is to be dynamically loaded, and a mechanism to search and load the module from a file. There is one place for a file: within a file hierarchy. And a file hierarchy has the rootfs at its top, watever it is, a hard disk, a cdrom, a flash memory, or a ramdisk. If there is an initramfs, then it is the rootfs, and the kernel launches init. Otherwise it must first mount the rootfs, which means that all the drivers needed to operate the disk and the partitions and perform the mount must be linked statically with the kernel (built-in). It is possible to choose which drivers to have, either all possible, or just the ones necessary for the hardware, but they must be either statically linked with the kernel, or stored in files. In the absence of an initramfs, a minimal set of drivers must be statically linked with the kernel. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
Le 04/01/2016 21:33, k...@aspodata.se a écrit : If you have a desire to move /lib/modules why don't move it and everything you need to boot to /boot. I don't want to move anything. I just don't care. And I think it has nothing to do with Systemd, except it comes in the same time. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] PAM usage (Was: Giving Devuan sans-initramfs capabilities)
> > But do any of you find useful to have PAM? Do any of you need > single-sign-on, > TPM, smart-cards that unlock ttys, integrate kerberos with linux, or the > like? > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > In many enterprise circles sso makes things a lot easier both for the employees and the administrators which I am sure many of you will agree. So authenticating against an Active Directory/LDAP server is commonly used. So personally I find pam useful, and powerful. But I can also say that it is too complicated, hard to get the configuration right, very easy to break your system while fiddling with it, and could have been implement in a better way. Nevertheless it is better than any systemd product ;) -- aldemir -- -- aldemir ___ 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
So I've been thinking more about this as to why? It is quite obvious that it is driven by Redhat to be the same as Oracle Solaris, they say as much. The base reason I can see is part of a marketing job showing the apparent ease of change when trying to sell Redhat servers to replace Oracle Servers. It is better to force Linux users to change if you can show potential high dollar clients that they don't have to. The support of the systemd folks and cronies is merely leverage across the distros. The Corporate vision is once again driving change for their benefit. To my simple mind the logic of the change seems backwards, I find it easier to see a case for sym linking from /usr to / than the other way round. Clarke "the guy in the tin foil fedora" ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] SystemD Casualty List (was Re: Devuan Weekly News LX)
Nate Bargmann wrote on 01/04/2016 09:48 AM: > SD now includes a replacement for running ntp/ntpdate to synchronize > time so that is being absorbed. It's probably a wash and low on most > desktop users list, but one more example of SD becoming your complete > middleware system! Anyone have an up-to-date casualty list of daemons/binaries that have been re-engineered for SD "compatibility"? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
chill...@use.startmail.com wrote on 01/04/2016 05:29 AM: > # Devuan News Issue LX > > In case you wondered, yes Devuan is alive and kicking. Devuan Weekly News > hasn't released a > single issue since last June. We're very sorry about that. Did you miss it? > [Tell us!][feedback] Definitely appreciate the work being put into this. It's hard to keep up with the traffic on the list so having an overview like this is certainly helpful. Thanks! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On 05/01/16 10:45, Daniel Reurich wrote: On 05/01/16 11:33, Daniel Reurich wrote: On 04/01/16 06:52, Go Linux wrote: Why are you merging the debian, backports and dmo repos? Is there a way to separate them? I have rarely used backports and always downloaded what I need from dmo when I first install and then disable it. dmo can really break things if you're not careful. We are currently merging dmo - was mostly done as a test for amprolla. I can ask nextime to remove that if it is causing breakages or other problems. Update: I have raised an issue about no longer merging dmo. There are a bunch of other reasons for removing it as well - but I won't discuss them here. Presumably the very same reasons that always prevented debian from including the convenient stuff in dmo in the first place (and caused mint to have a couple of versions). Users must add them independently if they wish too ... perhaps via dmo if that repo covers their needs, or via applications offering .deb downloads directly from their site. But aside from that look at the long long history of debian multimedia issues, users complaining of sudden breakages in debian packages, fixed by "remove dmo and load the debian libraries that the package was built against instead". Perhaps also the very very problematic relationships involved, over a very long time. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On 05/01/16 10:45, Daniel Reurich wrote: Update: I have raised an issue about no longer merging dmo. There are a bunch of other reasons for removing it as well - but I won't discuss them here. Thank you very much for that. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX (Errata)
On Mon, 4 Jan 2016 16:53:00 +, hellekin wrote in message <568aa36c.9010...@dyne.org>: > On 01/04/2016 03:07 PM, Arnt Karlsen wrote: > >> > >> https://git.devuan.org/devuan-editors/devuan-news/wikis/past-issues/volume-03/issue-060 > >> > >> tips about UUID's][2], Arnt Karlsen talked about the [purpose of > > > > ..er, I did not, I asked the (I believe timely) question > > "..where did the "/media tradition" come from anyway? " > > and thenafter it was Stephanie Daugherty who _answered_ > > my question by talking about said purpose. > > > > Thank you for this correction, Arnt. It's been corrected on the Web > version. ...with the "overstruck(Arnt Karlson) Stephanie Daugherty" revenge. ;o) Try "Stephanie Daugherty" the way you should have in the first place. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On 05/01/16 08:10, Svante Signell wrote:
On Mon, 2016-01-04 at 20:43 +, Rainer Weikusat wrote:
k...@aspodata.se writes:
chaosesquet...@cock.li:
I don't understand the desire to change it at all.
See UsrMerge discussion on debian-devel. They wan to move most stuff in / to
/usr and make it readonly. (The only sensible motivation I've found so far is
for NFS, but how many people use that?
It would seem to be a potentially useful tool in managing a fleet of locked-down
desktops with the end users prevented from modifying their system.
It would also be helpful if a vendor wanted to sell locked-down desktops without
root access, the way Samsung does very profitably with their android systems ...
using selinux to limit what the user can do ('owner' doesn't seem an accurate
word for the person who acquires such a device, while that system remains in place).
Or perhaps set up a flock of virtual servers with shared read-only systems.
All of which are the kind of use-cases the people pushing the changes in debian
hope to make $$$ from, and they are real and valid use-cases. But they are all
the exact opposite of the original motivation for debian, GNU and everything
most people here believe in. Instead those use-cases should be developed and
maintained within the corporate budgets that hope to profit from them, within
their own distributions ... Red Hat, Canonical etc.
It is very grim that Debian has allowed itself to be co-opted as a cheap
resource for those companies, but really I do not believe that will be the
outcome ... more likely it will just be knackered in a way which leaves less
choice for the less sophisticated end user and persuades more open source
developers to focus on making their work fully compliant with those corporate
oriented distributions. Fantasies of becoming the android of the desktop, with
app stores and advertising revenue flowing in their direction. Not likely, the
direct consumer market is already taken, by Samsung, Apple, Google, Facebook etc
... and they have much much bigger resources to deploy in keeping it.
Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
