Re: [Dng] systemd free badge
Joel Roth [2015-02-21 10:46]: Brainstorming here, I'm thinking about Coke Classic. So, what are the classical (or traditional) things we are preserving by excising systemd? Classical Unix Architecture Classical Unix Administration Classical Unix Services Classical Unix Security Classical/traditional AASS means you don't need to hire special consultants, just competent Unix developers/administrators. Cheers, A bit unrelated, we have a good beer here in Norway called Aass Classic. Aass from Drammen is our oldest remaining brewery (1834). -- Hilsen Harald ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: Linux kernel and the force behind it
On Sun, 22 Feb 2015, Didier Kryn wrote: I must confess I discovered ZeroMQ recently; it looks like the thing the programmer always needed since the advent of networking. I was blaming myself for not having used it in a multi-host+multi-language project started 7 years ago, but, well, it didn't exist yet :-). let me warn you, having used zmq extensively for various jobs, that unfortunately it does not deliver everything it says. At least for me it was so until a couple years ago, for instance with its pub/sub protocol and more. In my +15yr programmers experience it has never been a smooth ride and I ended up saving time reimplementing my own procedures on top of basic UDP and TCP functions - or reverting to older versions which worked more reliably before adoption of zmq, this was the case with syncstarter.org for instance. its a pity because it looks very good and aims at good directions, I hope it keeps improving. so well, your mileage may vary, but my experience and that of a couple good programmers we have at dyne.org has been always quite negative. And even if it would work, I don't think zmq would be a good solution to adopt as networking library for an ORB broker. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] GDM switched to wayland by default
Jaromil wrote on 02/22/15 04:28: At the very least, we may want to make sure that people is still free to choose between wayland and X11, but hopefully this will be also something that Debian wants. https://git.gnome.org/browse/gdm/commit/?id=ab90bd38c5cf2236c3527cf7ef6b9f383218a9e5 At first I thought this was Gnome doing something stupid. Then I realized it was just Redhat hard at work Poetterizing something. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] KDE systemd lock-in
Le 21/02/2015 19:52, Nate Bargmann a écrit : Imagine the chaos if the maintainers of the C library behaved in a like manner (okay, we'd have Python, but I digress;-) Let's hope GNU will keep away from systemd! Imagine GCC, LaTeX or Emacs depending on it :o By the way, I read in this list that Torvalds does not care of systemd, but did Stallman express any opinion? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] GDM switched to wayland by default
hi all, this is interesting and Devuan could cover also a role here since wayland is going to impact a lot of users with its lack of remote screen and of ACL permission control. At the very least, we may want to make sure that people is still free to choose between wayland and X11, but hopefully this will be also something that Debian wants. https://git.gnome.org/browse/gdm/commit/?id=ab90bd38c5cf2236c3527cf7ef6b9f383218a9e5 local-display-factory: use wayland by default for greeter, fallback to X11 This commit flips the big red switch, now we use wayland by default on the greeter and only fallback to X / legacy code paths in exceptional situations. https://bugzilla.gnome.org/show_bug.cgi?id=744764 ciao -- Jaromil, Dyne.org Free Software Foundry (est. 2000) We are free to share code and we code to share freedom Web: https://j.dyne.org Contact: https://j.dyne.org/c.vcf GPG: 6113 D89C A825 C5CE DD02 C872 73B3 5DA5 4ACB 7D10 Confidential communications: https://keybase.io/jaromil ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: Linux kernel and the force behind it
Le 20/02/2015 16:25, Gravis a écrit : D-Bus has existed for about a decade if not more. As far as I can tell, ZeroMQ has existed for a few years. Also, D-Bus is written in the fashion that matches how the GTK API which is a C API. libdbus has lots of language wrappers. D-Bus is more for RPC than IPC which is an issue as there is no standard in POSIX for RPC. Thanks Gravis for putting exact data in the discussion It makes more sense. Nevertheless, I think RPC is overkill for DE's interaction with hardware events. I guess it is mostly dedicated to provide Gnome's or KDE's integrated apps a better interaction with their respective window-manager than foreign apps. I must confess I discovered ZeroMQ recently; it looks like the thing the programmer always needed since the advent of networking. I was blaming myself for not having used it in a multi-host+multi-language project started 7 years ago, but, well, it didn't exist yet :-). Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] XFCE et al
On Friday, 20 de February de 2015 17:17:16 Jaromil escribió: [...] please go ahead, we count on everyone here to take initiative and do what one thinks can be useful for the progress of this project, which is not just made of code, obviously. True. There are Devuan Weekly News as well ;) To elaborate a bit more: I am a long time Unix Administrator, but not really a programmer. So I decided to help the project in a way I can be useful: by creating (first) and helping (now) the weekly news. Put shy at a side: this is not Debian, and there are no Debian Developers looking other contributors over the shoulder. As a shoemaker company said, Just Do It. er Envite -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? OpenPGP key: 1586 50C8 7DBF B050 DE62 EA12 70B4 00F3 EEC7 C372 Spiral galaxies always have at least TWO arms. signature.asc Description: This is a digitally signed message part. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] OT - It may be only one file, but it does point to the bigger problem!
Hi, First let me make it clear I'm not a fan of either systemd of journald. I've been watching the btrfs-linux mailing list, when the following subject popped up a few days ago: Systemd 219 now sets the special FS_NOCOW file flag for its journal files, possibly breaking RAID repairs.[1] From what I can glean from the thread and from [systemd-devel] [ANNOUNCE] systemd 219[2] the concern is for the ability of btrfs to recover the systemd-journald file if it becomes corrupted. Poettering seems to be concerned about write speed, the reason for setting FS_NOCOW it the first place. I wonder it the speed issue is due to the fact that his team are all developing on systems with SSDs. There was also the statement that the way FS_NOCOW is set, it only involves the one file and not the filesystem itself. I didn't see anything that contradicted that statement, but I could have missed it. Part of the discussion: btrfs checksumming theoretically allows you to transparently recover after media corruption if filesystem has redundancy (more than one copy of data). Journald checksum will probably detect corruption, but can it repair it? No it cannot. But btrfs checksumming cannot fix things for you either if you lose non-trivial amounts of data. It might be able to fix a few bits of errors, but not non-trivial amounts. I mean, that's a simple property of error correction codes: the more you want to be able to correct the longer must your checksum be. Neither btrfs' nor journald's are substantial enough to correct even a sector... Lennart If I have a btrfs mirror and I didn't mess with it by setting FS_NOCOW, shouldn't I be able to recover the file? I would sure hope so. He creates this better way of logging, then he seems to not even care if you can use it. Systemd, to me, is a horror story. The more I read the scarier it gets. At the very beginning of the 219 Lennart announcement you find this: Note that this version is not available in Fedora F22/F23 yet. The linker on ARM segfaults. Since the i386 and x86_64 versions built fine, I decided to release 219 anyway. Onward no matter what. Ready or not here systemd comes. We can only hope that, sooner rather then later, it catches up with them and bites them, you know where. [1] The archive for the thread starts here: http://thread.gmane.org/gmane.comp.file-systems.btrfs/43187 [2] The actual Systemd 219 announcement and LONG discussion can be found here: http://lists.freedesktop.org/archives/systemd-devel/2015-February/028447.html Just another 2¢ in the pot. Has anyone been keeping track of how much is in the pot? :-) Jim ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] UEFI secure boot not secure
Hi, this is a little off-topic, but still relevant I think. You all might remember that about a month ago I made a post about how I had partitioned my laptop hard drive GPT-style, which requires UEFI boot. I did this mainly to learn about GPT and UEFI, not because I wanted to dual-boot with Windows (because I don't in fact use Windows, at all). My post was just to ensure that Devuan would be able to handle UEFI boot. A few people later replied that MBR boot was at least as good, if not better. I didn't really think that it mattered, so I don't have anything to say about that. But then today I saw this: New Vicious UEFI Bootkit Vulnerability Found for Windows 8 http://www.theregister.co.uk/2012/09/19/win8_rootkit/ That got my attention. And with a little more googling, I learned that UEFI boot in fact is quite a bit more likely to compromised than BIOS boot, because you can place rootkits undetectable for the OS in the preload. Microsoft's answer to this is to enable secure boot, but now it seems that even that has been compromised. Your best protection would be to own a motherboard that only has BIOS boot capability. But such boards are now becoming scarce, though you can still find that in new server motherboards (such as those made by Tyan) On consumer motherboards, BIOS is pretty much history. Nevertheless, a UEFI motherboard is probably safe (or at least safer) if you disable UEFI boot and enable CSM (compatibility support module) so that you can partition the drive MBR style. Doing that, of course, means that you don't get to take advantage of the dubious benefits of GPT partitioning, but unless your hard drive is larger than 2TB, I don't think you'll notice the difference. cheers, Robert ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] GDM switched to wayland by default
On Sun, 22 Feb 2015 10:43:37 -0500 Steve Litt sl...@troubleshooters.com wrote: Isn't Wayland so systemd encumbered that somebody's going to need to write an alternative? I think Wayland is going to be the main issue in Jessie++, because it was implemented with a systemd dependency right from the start. We can't just rebuild it with legacy ConsoleKit support. -- Dima Krasner, dimakrasner.com pgplAp8hYpa_K.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] UEFI secure boot not secure
On Sun, Feb 22, 2015 at 4:20 PM, Gravis rin...@adaptivetime.com wrote: As recent news has shown, we also need to start writing new firmware for our hard drives. Since so many things have shown to be insecure, the question has becomes if it's worth reverse engineering proprietary systems versus engineering a libre systems from the ground up. That's easy in software, but hardware and firmware doesn't seem as easy. OpenMoko kinda did it, but i don't see big manufacturers lending a hand or you building an SDD in your garage. Reverse engineering seems viable at the moment. Cheers, Nuno ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] three important UI features
On Sun, 22 Feb 2015 20:11:12 + (UTC) Jonathan Wilkes jancs...@yahoo.com wrote: 1) In the default desktop environment for Devuan, will there be an icon or other discoverable item the user can click to see a list of available wifi network connections? #1 is vital because it makes the entire knowledge-base on the web (potentially) available for users so they can troubleshoot problems outside of network connectivity, even if they haven't a clue what an ESSID is. It should be easy to ship Devuan with a Wicd icon on the desktop... Cheers, Ron. -- Democracy is also a form of worship. It is the worship of Jackals by Jackasses. -- H. L. Mencken -- http://www.olgiati-in-paraguay.org -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] KDE systemd lock-in
This was inevitable and expected. I'm not trying to be an I told you so but I have mentioned this is a likely scenario before now. It's not the end of the universe, however. You can: a) patch the affected code. b) Use a shim that provides traps for both services without actually using Systemd. As a consolation, there are projects to provide a more permanent answer to this problem. Let's hope GNU will keep away from systemd! Imagine GCC, LaTeX or Emacs depending on it :o There is no reason for applications to have dependencies on systemd itself. Systemd is an operating system component, not an application interface. Even if some genius decided to try it, it is in the majority interest not to do so. It would require patching the every application every time that systemd was patched. By the way, I read in this list that Torvalds does not care of systemd, but did Stallman express any opinion? I personally do not care what Stallman's opinion is, because his views - while perfectly valid ones - do not function in the real world as a whole. If he had his way, Linux would have far fewer drivers and be virtually unusable. Corporate sponsors wouldn't touch it, and the state of everything would probably still be early 90s. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] OT - It may be only one file, but it does point to the bigger problem!
Systemd, to me, is a horror story. The more I read the scarier it gets. At the very beginning of the 219 Lennart announcement you find this: Note that this version is not available in Fedora F22/F23 yet. The linker on ARM segfaults. Since the i386 and x86_64 versions built fine, I decided to release 219 anyway. Systemd has its problems, I agree. However, that said, before you take anyone - even Lennart - to task on such a comment, please consider objectively that it may not be a code problem, but in fact a compiler problem. I'm am not familiar with the specifics of the situation, but I felt compelled to mention that GCC has a long history of processor specific problems, which I have experienced firsthand. The only truth that I can be certain of from reading this is that GCC works best only on x86 processors, and that has not changed in nearly 2 decades. It is also true that a lot of opensource code, even the Linux kernel, presently only compiles properly on GCC, rather than others such as Clang/LLVM. Onward no matter what. Ready or not here systemd comes. We can only hope that, sooner rather then later, it catches up with them and bites them, you know where. In keeping with commonsense and not hysteria, I hope they do fix things with eventually, but the truth is that compilers - regardless of language - can be finicky beasts from one processor family to the next. T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] three important UI features
Hello,A few questions about the GUI for Devuan... 1) In the default desktop environment for Devuan, will there be an icon or other discoverable item the user can click to see a list of available wifi network connections?2) When the DE's main menu pops up, will the user be able to _immediately_ start typing characters and see a list of applications filtered to match what is being typed?3) In the default desktop environment for Devuan, when the user clicks the Super key (often has the Windows icon on it) will the DEs main menu pop up? I put these three features in order of importance for newcomers and non-technical users to have control over their machines. #1 is vital because it makes the entire knowledge-base on the web (potentially) available for users so they can troubleshoot problems outside of network connectivity, even if they haven't a clue what an ESSID is. #2 is important because responsive natural language searches are ubiquitous, simple to understand, explain, and remember, especially when compared with branches of app categories (which are often quite arbitrary). #3 is certainly not vital at all, but its existence is a good indicator that the developers take usability seriously. You may be able to guess that I currently use Gnome 3 under Debian, because Gnome 3 includes all three features that I list. But please don't be mistaken-- I'm not looking to pitch Devuan on Gnome 3. Rather, I have neglected to uninstall Gnome 3 because as long as it does those three things it fulfills my needs as a user. I'd much prefer to use a distro like Devuan, where its community is reflecting upon the long-term maintainability of the system (and closely inspecting its source code). As long as it has a default DE with the three features above, I can switch over with virtually no pain. But more importantly, with those three features an entire class of non-technical users can have a safe, sane, and secure place from which to launch Chromium. I'd bet a large chunk of Lenovo's userbase has a desire for just such a system atm. :) Anyhow, if any of those three are missing under the planned system, I'd be happy to help try to rectify the situation. Best, Jonathan ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] three important UI features
On Sun, Feb 22, 2015 at 05:31:34PM -0300, Renaud OLGIATI wrote: On Sun, 22 Feb 2015 20:11:12 + (UTC) Jonathan Wilkes jancs...@yahoo.com wrote: 1) In the default desktop environment for Devuan, will there be an icon or other discoverable item the user can click to see a list of available wifi network connections? #1 is vital because it makes the entire knowledge-base on the web (potentially) available for users so they can troubleshoot problems outside of network connectivity, even if they haven't a clue what an ESSID is. It should be easy to ship Devuan with a Wicd icon on the desktop... I'm still on Debian Jessie. I use XCFE and when it comes up there's a wicd icon on the icon bar at the top of the screen. Mouseover tell me I have a connection, or it's trying to connect, or something like that. Will that do? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] vdev status update
On Sun, Feb 22, 2015 at 08:00:58PM -0500, Jude Nelson wrote: I consider vdev closer to being done than closer to having been just started, and it's mature enough that early testers can start experimenting with using it to boot Devuan in a VM (maybe even on real hardware, if you're the adventurous type). Not only does it create all device files in /dev that you'd expect, but also it set up and maintains the directories and symlinks for: * /dev/block * /dev/char * /dev/bus * /dev/bsg * /dev/cpu * /dev/disk/by-id * /dev/disk/by-uuid * /dev/dri * /dev/cdrom, /dev/cdrw, /dev/dvd, /dev/dvdrw * /dev/input/by-path * /dev/mapper * /dev/net * /dev/rtc * /dev/snd/by-path * /dev/v4l I had just been wondering how to set up /dev/disk/by-id; I have a helper for mdev that will set up /dev/disk/by-uuid/ and /dev/disk/by-label/ symlinks (by parsing the output of 'blkid'): https://github.com/idunham/mdev/blob/master/helpers/disk_link.sh It's released into the public domain via the unlicense. snip === TODO === There's still a few major shortcomings before I'm comfortable tagging an alpha release, which I list below: * vdevd needs an accompanying init script to mount devtmpfs and set up: -- /dev/stdout -- /dev/stderr -- /dev/stdin -- /dev/core -- /dev/shm -- /dev/MAKEDEV -- /dev/fd -- /dev/log -- /dev/xconsole -- and probably others ln -s /proc/kcore /dev/core ln -s /proc/self/fd /dev/fd ln -s /proc/self/fd/0 /dev/stdin ln -s /proc/self/fd/1 /dev/stdout ln -s /proc/self/fd/2 /dev/stderr # MAKEDEV is part of package makedevs; # it should be copied to /dev if it exists [ -x /sbin/MAKEDEV ] cp /sbin/MAKEDEV /dev/MAKEDEV || \ ln -s /bin/true /dev/MAKEDEV /dev/log is the responsibity of the syslog implementation, which is not started by the device manager. /dev/xconsole is not something I have on my main (udev-based) partition - I think it's the result of running xconsole? /dev/shm is either a mountpoint for a tmpfs filesystem or a link to one. An old FHS-style system will do: mkdir /dev/shm mount -t tmpfs shm /dev/shm On systemd-influenced systems, it's instead roughly: # in mountdevsubfs.sh, from initscripts mount -t tmpfs tmpfs /run mkdir -p /run/lock /run/shm mount -t tmpfs tmpfs /run/lock mount -t tmpfs tmpfs /run/shm #in udev, which runs before mountdevsubfs.sh mountpoint -q /dev/shm/ umount /dev/shm/ mountpoint -q /dev/pts/ umount /dev/pts/ #(re)mount /dev and populate it mkdir -p /dev/pts mount -t devpts devpts /dev/pts #I'm not sure where this is. ln -s /run/shm /dev/shm HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] WIP: mdev packaging
On Fri, Feb 20, 2015 at 06:12:11PM +0100, Jaromil wrote: dear Isaac, On Fri, 20 Feb 2015, Isaac Dunham wrote: On Sun, Feb 15, 2015 at 04:27:55PM +, Luke Kenneth Casson Leighton wrote: http://lkcl.net/reports/removing_systemd_from_debian/ Somehow, this inspired me to poke at packaging mdev. I don't have a website or apt repository atm, so I can't provide a deb. But here's the source in git: https://github.com/idunham/mdev To build it, use dpkg-buildpackage -b. if you like to use our CI system and apt repository, you are welcome. we can open an mdev project on our gitlab inside a new group for the sort of projects like vdev and mdev, something called packages-nextgen, there you'd be able to push mdev as a mirror in addition to your github the advantages for this would be multiple: you'd have continuous integration on mdev and the correctly built packages would be ready to use from the Devuan repository, making it much easier for people to test and give you feedback. Thank you very much. That sounds nice. I'm curious whether this works nicely with debian-source-native packaging, like I'm using for mdev (everything including the packaging and source is in git master). I suppose I should also package libsysdev, since Jude was talking about using it for parts of libudev-compat. If you're wondering why I didn't respond sooner: lkcl and I were chasing down a bug, which turned out to be breakage with initramfs-tools from wheezy. I also didn't want the mdev package to be something that someone *could* install easily at that stage, since the only other person to try it got a boot failure; at a certain point, someone who isn't ready to build the package probably isn't ready to help test it. But now that lkcl has figured out how to fix the bug, I suppose it's ready for putting into an experimental repository. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] three important UI features
dear Jonathan, you have very good concerns on usability. After Devuan 1.0 we might be able to quick fix desktop behaviour, I bet many developers involved will go do respins and blends. however, for what concerns us here and at least until the Devuan 1.0 release (which is a base system) you might have more chances interacting with the XFCE and the Mate projects, which are the main desktop environments Devuan offers on liveboot/install and are used by many other distributions. This way your contribution would have also a broader reach. in any case, thanks for sharing with us your recommendations! ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] vdev status update
Hi Isaac, I had just been wondering how to set up /dev/disk/by-id; I have a helper for mdev that will set up /dev/disk/by-uuid/ and /dev/disk/by-label/ symlinks (by parsing the output of 'blkid'): https://github.com/idunham/mdev/blob/master/helpers/disk_link.sh It's released into the public domain via the unlicense. Thanks! This is exactly the information I was going to have to go hunt down for next week. /dev/xconsole is not something I have on my main (udev-based) partition - I think it's the result of running xconsole? I think rsyslog creates it, after a bit of googling. Same with /dev/log. Thanks for the insights on setting up temporary filesystem mounts. I've always thought it odd that these mounts aren't included in /etc/fstab. I guess it has to do with the fact that the mount scripts try to calculate the tmpfs size based on the amount of RAM available? It makes me think it would be simpler to just regenerate the mount options in /etc/fstab if the amount of RAM was detected to have changed (and even then, only at the admin's request--perhaps as a special comment in the file that indicates as such). Thanks, Jude On Sun, Feb 22, 2015 at 10:17 PM, Isaac Dunham ibid...@gmail.com wrote: On Sun, Feb 22, 2015 at 08:00:58PM -0500, Jude Nelson wrote: I consider vdev closer to being done than closer to having been just started, and it's mature enough that early testers can start experimenting with using it to boot Devuan in a VM (maybe even on real hardware, if you're the adventurous type). Not only does it create all device files in /dev that you'd expect, but also it set up and maintains the directories and symlinks for: * /dev/block * /dev/char * /dev/bus * /dev/bsg * /dev/cpu * /dev/disk/by-id * /dev/disk/by-uuid * /dev/dri * /dev/cdrom, /dev/cdrw, /dev/dvd, /dev/dvdrw * /dev/input/by-path * /dev/mapper * /dev/net * /dev/rtc * /dev/snd/by-path * /dev/v4l I had just been wondering how to set up /dev/disk/by-id; I have a helper for mdev that will set up /dev/disk/by-uuid/ and /dev/disk/by-label/ symlinks (by parsing the output of 'blkid'): https://github.com/idunham/mdev/blob/master/helpers/disk_link.sh It's released into the public domain via the unlicense. snip === TODO === There's still a few major shortcomings before I'm comfortable tagging an alpha release, which I list below: * vdevd needs an accompanying init script to mount devtmpfs and set up: -- /dev/stdout -- /dev/stderr -- /dev/stdin -- /dev/core -- /dev/shm -- /dev/MAKEDEV -- /dev/fd -- /dev/log -- /dev/xconsole -- and probably others ln -s /proc/kcore /dev/core ln -s /proc/self/fd /dev/fd ln -s /proc/self/fd/0 /dev/stdin ln -s /proc/self/fd/1 /dev/stdout ln -s /proc/self/fd/2 /dev/stderr # MAKEDEV is part of package makedevs; # it should be copied to /dev if it exists [ -x /sbin/MAKEDEV ] cp /sbin/MAKEDEV /dev/MAKEDEV || \ ln -s /bin/true /dev/MAKEDEV /dev/log is the responsibity of the syslog implementation, which is not started by the device manager. /dev/xconsole is not something I have on my main (udev-based) partition - I think it's the result of running xconsole? /dev/shm is either a mountpoint for a tmpfs filesystem or a link to one. An old FHS-style system will do: mkdir /dev/shm mount -t tmpfs shm /dev/shm On systemd-influenced systems, it's instead roughly: # in mountdevsubfs.sh, from initscripts mount -t tmpfs tmpfs /run mkdir -p /run/lock /run/shm mount -t tmpfs tmpfs /run/lock mount -t tmpfs tmpfs /run/shm #in udev, which runs before mountdevsubfs.sh mountpoint -q /dev/shm/ umount /dev/shm/ mountpoint -q /dev/pts/ umount /dev/pts/ #(re)mount /dev and populate it mkdir -p /dev/pts mount -t devpts devpts /dev/pts #I'm not sure where this is. ln -s /run/shm /dev/shm HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] vdev status update
Hey everyone, In keeping with the request to give more frequent status updates on development, here's where things stand now with vdev. === CURRENT STATUS === I consider vdev closer to being done than closer to having been just started, and it's mature enough that early testers can start experimenting with using it to boot Devuan in a VM (maybe even on real hardware, if you're the adventurous type). Not only does it create all device files in /dev that you'd expect, but also it set up and maintains the directories and symlinks for: * /dev/block * /dev/char * /dev/bus * /dev/bsg * /dev/cpu * /dev/disk/by-id * /dev/disk/by-uuid * /dev/dri * /dev/cdrom, /dev/cdrw, /dev/dvd, /dev/dvdrw * /dev/input/by-path * /dev/mapper * /dev/net * /dev/rtc * /dev/snd/by-path * /dev/v4l Unlike udev, the logic to handle the aforementioned files is handled by simple shell scripts and ini files. To keep things simple, vdevd only knows how to (1) probe sysfs and listen for device events, (2) match device events to vdev actions, (3) mknod or unlink the device file proper, and (4) execute shell scripts which go on to rename or set up the device files and symlinks, using data passed in from the kernel via vdev as environment variables. I've taken the liberty of providing a set of shell scripts, a shell library, and utility programs that will cause vdev to set up your /dev/ in a manner as close to how udev does it as possible (in fact, a lot of code in said utility programs is imported from udev, but stripped of their libudev dependencies). === TEASER === Getting vdevd to take device-specific actions is very straightforward if you're familiar with basic shell scripting. The utility programs and shell library handle the intricacies of probing for device drivers, subsystems, and capabilities, as well as managing per-device metadata and tracking per-device symlinks. All that remains is to put device files and symlinks in the right places. As an example, here's how you'd get vdevd to set up the symlinks in /dev/char: (1) Create a vdev action file that tells vdev to run a script whenever it adds or removes a character device: $ cat example/actions/char.act [vdev-action] event=any type=char command=exec $VDEV_HELPERS/char.sh (The line on the command= directive gets fed directly into /bin/sh; $VDEV_HELPERS is the path to the directory holding shell scripts and programs to set up devices, akin to /lib/udev). (2) Create a script to implement the action: $ cat vdevd/helpers/LINUX/char.sh #!/bin/sh . $VDEV_HELPERS/subr.sh case $VDEV_ACTION in add) add_link ../$VDEV_PATH $VDEV_MOUNTPOINT/char/$VDEV_MAJOR:$VDEV_MINOR $VDEV_METADATA ;; remove) remove_links $VDEV_METADATA ;; *) fail 1 Unknown action '$VDEV_ACTION' ;; esac exit 0 (All variables prefixed with VDEV_ are passed to the script via vdevd. add_link and remove_links are subroutines from $VDEV_HELPERS/subr.sh that let you keep track of which symlinks you created for a device). In addition to simplifying device setup/shutdown, vdev preserves the information that you'd normally get from udevadm info under a directory tree in /dev/vdev. Within this directory are directories for each device file, and in each of these directories are a set of files that correspond to uevent variables passed to vdev from the kernel as well as any runtime metadata created by the utility shell library (i.e. listing of symlinks). For example: $ ls dev/sda # my hard drive dev/sda $ ls dev/vdev/sda/ # dev/sda's metadata DEVNAME DEVPATH DEVTYPH links SUBSYSTEM SYSFS_MOUNTPOINT $ cat dev/vdev/sda/DEVPATH # dev/sda's sysfs devices path /devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda === TODO === There's still a few major shortcomings before I'm comfortable tagging an alpha release, which I list below: * vdevd needs an accompanying init script to mount devtmpfs and set up: -- /dev/stdout -- /dev/stderr -- /dev/stdin -- /dev/core -- /dev/shm -- /dev/MAKEDEV -- /dev/fd -- /dev/log -- /dev/xconsole -- and probably others * There are no scripts yet to handle /dev/input/by-id and /dev/vboxusb, and probably others that I haven't encountered since I've thus far only tested it on my laptop. * There is no man page yet. I'll make some wiki pages at some point which hopefully will become man pages. * vdevd only partially supports run-once semantics. The idea is that users who don't need vdevd to be running all the time can instead run it periodically or manually to have it populate and repopulate /dev with device files for currently-installed hardware. vdevd populates /dev, but it does not yet remove files from between invocations (although it keeps track of the necessary data to do so under /dev/vdev). * vdevfs, the per-process device access control filesystem that can optionally overlay /dev and hide device files from unprivileged processes (for an admin-defined (!!) definition of unprivileged), does not yet support
Re: [Dng] vdev status update
Hey Jaromil, isn't the script called with execve or similar, so one can just choose any shell? Yes. Specifically: execle( /bin/sh, sh, -c, cmd, (char*)0, env );, where cmd is the contents of the command= directive, and env is the list of vdev-exported environment variables (all prefixed with VDEV_). NB: Vdev delegates setting up the shell environment beyond this to the admin to ensure that a well-known PATH gets set, and to ensure that nothing sensitive leaks over from vdev's environment to the script. -Jude On Sun, Feb 22, 2015 at 9:16 PM, Jaromil jaro...@dyne.org wrote: hi Jude, On Sun, 22 Feb 2015, Jude Nelson wrote: Hey everyone, In keeping with the request to give more frequent status updates on development, here's where things stand now with vdev. many thanks! one quick q (sry if I don't answer it myself looking at the code...) (1) Create a vdev action file that tells vdev to run a script whenever it adds or removes a character device: $ cat example/actions/char.act [vdev-action] event=any type=char command=exec $VDEV_HELPERS/char.sh (The line on the command= directive gets fed directly into /bin/sh; $VDEV_HELPERS is the path to the directory holding shell scripts and programs to set up devices, akin to /lib/udev). what do you mean by fed directly into /bin/sh ? isn't the script called with execve or similar, so one can just choose any shell? thanks ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Looking for advices in preparation to switch from Debian to Devuan
No comment anyone? Ok then. I guess I will have to test it myself later on. For those with the same objective, I decided to keep my PC and 2 VPS' at the current Debian Testing packages, but striped systemd and its components as much as possible. There are still files especially on /etc/systemd, /lib/systemd and /var/lib/systemd but the only package matched with *systemd* is libsystemd0. It is currently at version 215-11. I pinned Package: *systemd* to Pin-Priority: -1 to make sure that they will not be pulled back again. I hope everything will still work with regular weekly update before I switch to Devuan. On 16/02/15 21:16, Anto wrote: Hello Everybody, I am not sure if this was due to a principle reason or ego, but I really want to have a Debian-like OS that is free of any systemd and its related packages. I just want to have a freedom to choose the packages that I want to use, instead of being forced to use the one and only. So I am preparing to switch my notebook and 2 of my Xen VPS' from Debian into Devuan. My notebook is currently running on Debian Jessie. It switched into systemd sometime last year after I did dist-upgrade. When I tried to roll that back, I ended up in dependencies hell. So I thought I keep it while I am waiting for LMDE2. Sorry, I didn't know about Devuan until about 2 months ago, hence the thought. But in any case, I don't have any issue to clean install it later on. I am more concerned with my 2 Xen VPS'. One of them is still running on Debian Wheezy and the other one on Debian Jessie. As you know, even on Debian Wheezy, some important packages are already locked into systemd, e.g. dbus and udev. So I am thinking to downgrade them to Debian Squeeze as my VPS providers still provide the image for that. I will possibly have to recompile some of the packages to have the same versions as the ones that I currently use. I just mainly need nginx, php5 and sqlite3 packages. But I am not really sure yet what problems will I get if I would recompile them in Debian Squeeze. Some required libraries might be too old for the new versions. So I really appreciate any advices to be able to smoothly upgrade my VPS' to Devuan later on. Thanks a lot in advance. Kind regards, Anto ___ 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
