Thankfully My Last Post
On Mon, 12 May 2014 12:00:48 +0200 A debian dev wrote: Nobody cares. Please go away. You apparently don't care that an official debian document is making sweeping incorrect statements even though I have told you I have professional experience in this area and pointed debian to a buildroot link multiple times that at the very least shows your page to be inaccurate. Devices are getting smaller and smaller and mhz aren't equivelent at all for any idiots out there, systemd is not even close to a Universal init. Perhaps it is still under consideration but you also don't seem to have given nearly enough consideration to su breakage and ploughed ahead with su eradication despite rc.local likely being used under systemd. Users not having read this thread will quite rightly from learning from much more authoritative sources than debian continue to use su in /etc/rc.local. Is there any danger to security of those users from doing that; unanswered and unconsidered? This is important as I guarantee users will continue to do so and likely forever and no amount of website writing will change that. The tech-ctte decision was 50/50 and the final statements largely ignored the crux of the issues, an obviously significant part??? of systemds 50% was based on licensing and not technical arguments that you keep insisting on whilst ignoring pro systemd non technical and incorrect statements. I have no preference for Upstart beyond over systemd but if Ubuntu did decide to inhouse it then how is that an issue. You still have a license to continue to use that code and develop it. It is quite rediculous when the technical consequences are far reaching and even affect Linux beyond debian that this should be a major factor especially when /sbin/init has been undeveloped for so long or do you want pid1 to be re-developed for ever. It has also been said that a fork may be required anyway due to the belligerent nature of upstream. Good intentions to develop for the good of the task itself for shared benefit is the main thing that counts outside of legal nonsense like patents. Perhaps there should have been tech-ctte decisions on the various points. Having just looked it up I am surprised Matthias Urlichs actually is a debian dev and suggest he qualifies his statements much more before making them? The Tech-Ctte output was rather poor largely due to the obfuscation systemd places on the crux of what it deals with and that is primarily why I tried to correct debian developers statements. Perhaps debian simply inherited the changes to su but no-one spoke against it in 1999 or 2000. I am sure Theo among others would have spotted that fundamental default behaviour change and the potential future danger and not allowed it to happen and this makes me appreciate OpenBSD even more. (I know PAM would thankfully have no chance of getting into OpenBSD but that is not the point) A major part of why I am leaving and investigating my options is because I see major management problems and do not believe debian is anywhere near as stable or universal as it purports to be, though much more than Fedora. ___ There are two ways of constructing a software design. One is to make it so simple that there are OBVIOUSLY no deficiencies. And the other is to make it so complicated that there are no OBVIOUS deficiencies Professor C. A. R. Hoare The 1980 Turing award lecture ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/372796.30485...@smtp141.mail.ir2.yahoo.com
Re: correct use of su
previously on this list Steve Langasek contributed: Yes. This has been the case for su in Debian since 1999, and to do otherwise would break a variety of configurations where session setup is required in order for, e.g., the su process to have access to the files of the target user. It seems to me that someone needlessly? dropped the ball in 1999 then and this should have perhaps been a new flag or added to -l where PAM is in use, as it fundamentally changes the behaviour contrary to the varying titles of su. Now done of course and for so long I wouldn't know what the fallout to debian and other things would be and so the best way to fix this bug today at all. I do know that I would much prefer if a script in rc.local that uses su to drop priviledges and maybe even then sudo to re-gain one or two worked on all unix-like systems and without having to deal with debians overly complex scripts in comparison to bsd or create a systemd unit (I think it's clear I wouldn't). However as I don't use polkit and use sudo to handle my suspending and shutdowns I think I probably could without issue anyway? Not being a PAM fan but only locking it down a little on systems with it. I can't say I fully understand the weight of grounds with which must not was stated though. I hope I don't get flamed as I am not enjoying or intentionally bashing these things for any political reason and I'm actually rather busy. I simply strive for what I see as simpler and better alternatives in ease of use/config and lack of exploits and don't believe I should have to hide anything. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/248613.30904...@smtp148.mail.ir2.yahoo.com
Re: Avoiding systemd
previously on this list Russ Allbery contributed: by the non-stop sniping (for *months* now) by people like Kevin Chadwick, Well I have only responded to incorrect statements and have tried to ignore any that are not from debian developers and may not affect the future of debian but you can't always tell if the person is a debian developer or not (no @debian.org or footer). I shall do myself and some of you a favour however but maybe not the world and unsubscribe as I think I will be unable to ignore everything especially incorrect or innacurate sweeping statements such as found on the following link which I assume is a form of consensus from the developers. https://wiki.debian.org/Debate/initsystem/systemd Embedded systems benefit from speed improvements, shell-less design, ability to remove optional components, and lower memory footprint. Perhaps I should mention that some of my work involves programming embedded systems including linux and deeper embedded. I have been considering my options (Slackware, but hopefully and most beneficially Openbsd and a linux kernel) recently anyway and whilst I won't cut off my nose to spite my face. I have been wondering if whilst having debian repos available of so many packages is convenient offline perhaps it is limiting me to an out of date subset of available compilable code when most additional tools are small and I am quite capable of fixing any issues with impact. Threads have also brought into question the security of those repos and DVDs, where I thought it was rather higher (atleast I know how trustable a program is if I download it manually). -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/773142.30904...@smtp148.mail.ir2.yahoo.com
Re: systemd-fsck?
previously on this list Matthias Urlichs contributed: I haven't yet seen a system where booting with init=/bin/bash works but booting systemd in emergency mode does not. Have you added me to a killfile? I mentioned such a bug as happened in Arch testing in this very thread or do you mean a debian system? How it wasn't found before hitting testing beats me but doesn't surprise me on arch. I imagine it wouldn't happen even on debian experimental as I would hope upstream code would be tested out of tree first? I got the impression it was a systemd release with the segfault but find that hard to believe too but perhaps arch used pid1 differently to upstream testers. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/639917.30904...@smtp148.mail.ir2.yahoo.com
Re: systemd-fsck?
previously on this list Matthias Urlichs contributed: Will a script doing this be portable to other Linuxes or even BSD Unices? No. BSD has daemon(8). If you want portability, you probably need to check what's available. (start-stop-daemon, daemon (on BSDs), sudo) I can tell you that not all systems (pclinux os and others) have sudo though I think they should and why should people know or re-learn how to use sudo for that. The only portable and intuitive thing almost guaranteed to be available is su, atleast it was. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/273168.30904...@smtp148.mail.ir2.yahoo.com
Re: systemd-fsck?
previously on this list Matthias Urlichs contributed: I also would not expect an end user to add su foo -c /do/whatever to /etc/rc.local. Your opinion may differ, that's OK. My opinion certainly does differ as I'm sure is already apparent ;-) especially that pid1 and single user should most certainly be technically held to a higher level of scrutiny where the decision to increase it's complexity has been decided (perhaps you meant the other parts of systemd though). I love sudo but do not use it in rc.local. How can using substitute user identity in rc.local possibly be wrong, please elaborate without mentioning PAM. I can't say I know the details but even so surely the bug has to be either with systemd or my expectation being PAM? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/704384.38987...@smtp111.mail.ir2.yahoo.com
Re: systemd-fsck?
previously on this list Steve Langasek contributed: Using systemd breaks something that worked for probably a decade or longer before however long that su is in that init script. So on what account do you call calling su in an init script a bug? It may not be the most elegant solution to do things, granted, but a bug? Come on. Calling it a bug just cause systemd / policykit treat calling su in an initscript as they do is quite arrogant in my eyes. As the maintainer of the pam package in Debian, I assure you: this is a bug in dirmngr. System services should not (must not) call interfaces that launch pam sessions as part of their init scripts. su is one of those interfaces. In that case should it be one of those interfaces. He is right, books tell you (for decades) quite rightly to do just that in rc.local for example. Examples are all over the internet, so if this breaks your system are you or RedHat going to change all those books and websites to say but if you are using Linux post 20?? you now have to do it differently unless you use Slackware or maybe Gentoo or???, that is irresponsible or bad planning or configuration or perhaps money in RedHat's pocket for support if I was inclined to be sinical. The su utility allows a user to run a shell with the user and group ID of another user without having to log out and in as that other user. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/101395.27220...@smtp148.mail.ir2.yahoo.com
Re: systemd-fsck?
previously on this list Simon McVittie contributed: That would let cautious systemd users keep the sysvinit binaries around, and boot with init=/usr/lib/sysvinit/init if something went horribly wrong with systemd. Not that it would affect me but that would be wise, an upstream bug caused arch testings pid1 to segfault not long after they switched. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/651368.84881...@smtp114.mail.ir2.yahoo.com
Re: standalone logind (Re: Bits from the systemd + GNOME sprint)
previously on this list Matthias Urlichs contributed: Hi, Kevin Chadwick: * last but not least: if you do have a tangible reason for your post, i.e. one of your packages doesn't work with the way systemd is packaged, kindly tell us which package that is and what you're trying to do. My first mail stated it. Did not. See below. There may be less to consider for a user/admin about dependence on the simpler or particular parts of the package for example. I have avoided root ipv6 exploits due to similar scrutiny. Why do you question it. Because I do not share your opinion. I guess I need to make sure I stick to one main point as you have twisted the first question and jumped on my responses even when I stated they weren't the raised issue. I guess I will have to remember that as it simply allowed you to distract from the raised issue and create more noise. Even the thread rename is wrong. There are multiple binaries in systemd-services so simply breaking them up into multiple packages means the dependency information needs to be considered once instead of wasting many admins time, never mind porters and embedded work. You know I have been considering but it now occurs to me that it may actually be easier to get something like alpine mini (a kernel and a small userland) running under qemu to handle a usb driver for a proprietary tool that enables a tcp port gdbserver or look at porting access to OpenBSD than deal with debian and systemd. Out of interest, how does debian kfreebsd compatibility with Linux only software fair? Look at all the tasks mentioned in the logind man page some of which are unneeded and complex and will have affects upon security. … which are …? Multi-seat management Session switch management Device access management for users Automatic spawning of text logins on virtual console activation and user runtime directory management. By unneeded and which I had already stated I meant by me. I need none of these and nor would any of my users or products. So why should the job of removal be harder than it could quite easily be and would be from almost any other upstream. More exploits will be found so why make the job of avoiding them where there is no downside more difficult. Especially when these two were quite dangerous. http://osvdb.org/search?search%5Bvuln_title%5D=logindsearch%5Btext_type%5D=alltext __ This has been twisted onto an init argument that I never intended somehow despite the closing line below. So as you haven't already you may wish to stop reading as this has nothing to do with the raised issue and is simply adding yet more noise. Like systemd in general, I question your assertion that splitting logind into separate programs has any effect other than needlessly increasing complexity. Now you have at least two programs whose services are necessary (or at least damn convenient) to have on a normal Debian system; also, these might need to talk to each other, above everything else they do -- so you get to debug two interacting asynchronous processes instead of one single-threaded one. Might need talk to each other is basically saying in many cases they don't and that is hardly difficult with many plus sides being: Competition; better code more easily and readily replaced with even better or more application specific code and with less devotion of time, easier porting and adaptability, ease of application specific changes, well defined tasks and implementations. More easily audited code, More easily understood code. Less exploitable code required in memory not to mention less memory required for any particular task to be accomplished. Using more memory in total means little in the face of the benefits of requiring less per task when you consider use cases. I could go on and talk for a very long time about this but you would be better off buying some books about the origins of Unix and why it works so well and on so many platforms and is so adaptable to so many completely different and diverse situations and purposes. As I'd like to keep d-devel civil (and mostly-technical), I will stop here. -- -- Matthias Urlichs -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick
Re: standalone logind (Re: Bits from the systemd + GNOME sprint)
previously on this list Matthias Urlichs contributed: Sorry, but I suspect the latter. Why did I expect any reasonable and balanced discussion! I suspect but haven't mentioned that I expect the reasons for bundling these components together to be on highly questionable grounds. Oh, you mentioned that plainly enough. Really why not quote then, you are an assuming liar and quote the only contentless part of my email which was a reply to your original assumption. A reasonable and balanced discussion may be started when somebody comes forward with legitimate technical problems. I did not perceive your concerns as such. * for better or worse, Debian decided on systemd as its future init system. As such it's probably going to be Priority: Standard, and Joe+Jane DD expect (IMHO entirely reasonably) that it's going to be all there. * you didn't actually state what the TECHNICAL problem is. I don't like it is not a technical reason. Another package will have problems replacing | turning off | not installing some part of systemd is (respectively) true but not demonstrated to be relevant | false | not deemed relevant given the wide availability of multi-GByte microSD cards * your signature has already been mentioned. If you state up front that you're not interested in a reasonable discussion, don't complain when it doesn't happen. I stand by it absolutely. There is no bias there only a deeply technically founded opinion. What has that got to do with being open minded and balanced on a point by point technical basis. You are the one being closed minded and dismissive. * last but not least: if you do have a tangible reason for your post, i.e. one of your packages doesn't work with the way systemd is packaged, kindly tell us which package that is and what you're trying to do. My first mail stated it. Why do you question it. Look at all the tasks mentioned in the logind man page some of which are unneeded and complex and will have affects upon security. Removing logind when apps expect it is potentially insecure too especially if many are like you and will not test this possibility. I have avoided root ipv6 exploits due to similar scrutiny. I don't see how you only caring about functionality and not security or correctness is any reasonable response. I guess there is no unlaborious way to see which programs depend on a particular binary of a given package? The people packaging systemd probably (I do not speak for them) did not see any good reason to split up these packages, for the reasons I mentioned in this and my last email. Nothing you mentioned touched on that at all. What would best practice be? If this is a real problem for you, kindly speak up and tell us why disabling logind with two quick systemctl commands, assuming that you _really_ do not need it, is insufficient. See above. Though I didn't know it could be disabled officially like avahi-daemon so thanks for that. It is still important for an admin to be able to quickly see what packages may have issues or how to avoid any unexpected security issues as a result of packages expecting it to be around. -- ___ There are two ways of constructing a software design. One is to make it so simple that there are OBVIOUSLY no deficiencies. And the other is to make it so complicated that there are no OBVIOUS deficiencies Professor C. A. R. Hoare The 1980 Turing award lecture ___ ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/806463.34955...@smtp118.mail.ir2.yahoo.com
Re: standalone logind (Re: Bits from the systemd + GNOME sprint)
previously on this list Matthias Urlichs contributed: The second case is a no-brainer. Many packages in Debian consist of more than one binary, of which you need at most one (if that). Do you really want to mass-file a bug against all of these _and_ the packages depending on them, or are you picking on systemd for non-technical reasons here? Sorry, but I suspect the latter. Why did I expect any reasonable and balanced discussion! I suspect but haven't mentioned that I expect the reasons for bundling these components together to be on highly questionable grounds. Something like avahi-daemon can be easily understood as what it is needed for and whilst I would like to remove it I can simply disable the service without any consideration as I know I have no use for it even if I use cups meaning an increases in security without any functionality loss for our users. Things like coreutils are used but not resident. With systemd-services knowing what it is doing is more important and being able to avoid complex resident code with minimal sacrifice should be possible. You could easily argue that just logind does far more in one binary than it should for reasonable system management never mind it being bundled with other especially potentially widely used functions like systemd-localed. After a quick look at the script I guess aptdaemon only needs localed. I guess there is no unlaborious way to see which programs depend on a particular binary of a given package? GDM can be easily avoided or uninstalled for example if you have no need for logind and perhaps there are alternatives for any others but the current situation means you have to cut out more or investigate far more than you should have to. And Yes KDE dependencies being so coarse grained do really annoy me but atleast KDE doesn't run by default. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/63894.49700...@smtp115.mail.ir2.yahoo.com
Re: A question about patches for upstream
previously on this list Bas Wijnen contributed: Which means that if the maintainer is unable to do that, the response please forward this upstream should be interpreted (and perhaps more clearly written) as sorry I don't have time, this is how you can try to make things happen yourself. Perhaps at the same time the minimum could be a debian dev anonymous email address that is used to simply send a link to the bug report to the upstream mailing list if they have one. It is not always easy for a user to find the right place/list/having to register possibly a second time etc.. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/553432.30578...@smtp104.mail.ir2.yahoo.com
Re: standalone logind (Re: Bits from the systemd + GNOME sprint)
previously on this list Michael Biebl contributed: Anyone interested in keeping standalone logind working is invited to help the systemd-shim maintainer to implement and test this functionality (it will most likely be using cgmanager for that as far as I heard). Having v208 out is a prerequisite for being able to test those changes in systemd-shim. Is it possible to break up systemd-services into multiple packages. I know our systems have no functional use for systemd-logind and yet lots seems to depend on it but it is less clear what depends on which parts and so why each of the many packages do so. Whilst avoiding segfaults is a valid reason to depend it is a bit silly when it is the only reason code is installed for some or in some cases almost all users. There may be less to consider for a user/admin about dependence on the simpler or particular parts of the package for example. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/326384.15025...@smtp144.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
previously on this list Tzafrir Cohen contributed: A wide misconception. Chroots are easily implemented and add security almost for free Not completely for free. You now have an extra mini-system to maintain. (often /dev/log is all that is needed) and so can be You completely misunderstand. Many daemons have chroot config options for security reasons. I am asking does Debian use them by default and if not why not. used by default without any potential problems, they also never bring new risks unless you forget to unpdate them. You don't need to update them, they are basically empty and created on daemon startup with perhaos one or two files like a dns root key for unbound which is then self maintained (better if writes could be avoided though). I am talking about dropping an unpriviledged process permissions to next to nothing running with no shell and no filesystem access so that any exploit in the network/any input code is far less likely to get any further. It's also worth mentioning systemd-nspawn: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html Not at all, it hasn't been tested for this, isn't supported by daemons that crucially use priviledge seperation, which involves forking children so a tiny process doing what root needs or a tiny process doing the dangerous stuff in a chroot as an unpriviledged user or a combination of both and any wrong communication means the priv parent dies), sounds like it does what most Linux admins think chroot is only good for and talks about all sorts of stuff that would make any chroot in this way pointless. more powerful I expect means less secure in this usage. p.s. this is proper security in quality daemons implementing application specific security not polkit/systemd rubbish. Whilst you have got me to mention systemd I shall bring something up that has yanked my chain. I suppose the debian page https://wiki.debian.org/Debate/initsystem/systemd Is just written by random developers and is not official or speaking as a debian collective because it is very unbalanced indeed. Embedded more performance less memory blah blah well that depends as systemd is NOT compatible with application specific embedded that basically is what embedded is all about and the Linux kernel is atleast for now and would be forked otherwise. I could argue further about larger systems but I won't bother, it would just be twisted and move away from the main point anyway. http://lists.busybox.net/pipermail/buildroot/2011-November/047612.html -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/25453.25357...@smtp118.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
On Fri, 02 May 2014 10:55:15 +0200 Aaron Zauner wrote: Bashing on Tor does not help here. The page suggests all devs use Tor to avoid being targetted. I am saying, does it accomplish that and is is best practice. Should they be hackable even if they are targetted or stumbled upon. I find that highly questionable and I am suggesting other simpler policies will be far more effective. Hiding is fine but not at the cost of complexity where security (confidentiality/protection/unexploitability) is paramount. I also mentioned ssh which I believe all the devs are using already. I am not going to say which VPN/SSH is best for the devs, I wouldn't know. I expect they would not choose commerical proprietary insecure CISCO you compare to TOR though in any case. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/519419.15824...@smtp146.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
previously on this list Kevin Chadwick contributed: all sorts of stuff that would make any chroot in this way pointless. more powerful I expect means less secure in this usage. p.p.s. why implement yet more code and complexity into systemd for preventing device files when you can just use the nodev filesystem flag. Yet another classic example of pointless arguably, more likely detrimental feature creep/steal and even worse when duplicating existing functions that can be applied more universally. Perhaps because of this quote taken from the opening page of a book about Ada and high integrity software. There are two ways of constructing a software design. One is to make it so simple that there are OBVIOUSLY no deficiencies. And the other is to make it so complicated that there are no OBVIOUS deficiencies Professor C. A. R. Hoare The 1980 Turing award lecture I think the one thing all should be able to agree on about systemd is that systemd falls into the latter. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/753535.36099...@smtp138.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
On Wed, 30 Apr 2014 18:33:56 +0200 Aaron Zauner wrote: It adds a lot of complexity for privacy benefit. Integrity is often muddled into security too. As far as I am concerned they can actually counter each other and are seperate entities. No they are not. Integrity should be part of your understanding of security. Basics of information security suggest confidentiality, integrity and availability. [0] Suggested Basics, yes and good to remember they may influence each other but I don't like mixing them up once that is understood personally. The desired level of Information security *may* have next to nothing to do with integrity and conversely availability can often be everything in a specific situation. It makes much more practical sense to keep integrity and availability as their own seperate entities. All too often the word secure is confused and abused or marketed. All too often I have witnessed it being said that X is more secure when actually it may be more exploitable but increases availability or integrity. Debian developers not being able to upload security fixes is part of the mix but then I would guess you could more easily bring down the TOR network too than a private VPN and filtering would be much more difficult so I would say TOR is not *optimum* for security or availability and obscurity is no real security though perhaps very occasionally the best possible ;-). Obscuring from targetted attack is highly questionable to me when a secure VPN from a lightly used machine (no web browsing) can offer real security. You may just be giving a way in otherwise. First I don't understand your first sentence. Second how does a VPN provide more security than say Tor? Tor is more complex, less proven, had more past exploits and crucially I believe? generally more reliant on external infrastructure. It's primary aim is privacy and not a simply secure protocol. I include SSH when I say VPN too but host security is paramount in any case. Devs avoiding html mail clients on machines with keys or access etc.. might be another idea. Was there a resolution on binary uploads? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/483967.32253...@smtp150.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
previously on this list people contributed: - easy create and run programs from chroot and alternate users Could you detail what you mean by this? It sounds like you want either virtual machines or something like docker.io: https://packages.debian.org/sid/docker.io hint: chroot $CHROOT_PATH su - $USER -c $command_with_args Security and chroots aren't things I would associate, you need better. A wide misconception. Chroots are easily implemented and add security almost for free (often /dev/log is all that is needed) and so can be used by default without any potential problems, they also never bring new risks and always make life difficult for an attacker to raise priviledges or get what they are actually after when done correctly. Even at a simple level it should be obvious that they can just nullify the payload so the attacker simply goes elsewhere. Does debian chroot unbound and nginx under their own unbound and nginx users by default? MACs are hardly ever used by default due to management problems and when they are they either may even lead to exploitable programs that cannot do what they expect to be able to or may not offer the protection expected and why not use the chroot under a MAC anyway. If the kernel can be attacked from the chroot then likely the MAC can and due to increased complexity, arguments just as easily arise against both. For most daemons where the filesystem access amounts to little then a MAC is unlikely to prevent any more attacks that chroot wouldn't and where a program needs a lot of access you are fighting a losing battle and you should rethink your attack surface. Time would be better spent on privsep or getting your web content to run without www-data writes via DACs than tuning a complicated MAC to allow it to some degree or writing a cgi program to keep things out of the chroot. What I am saying is MACs are fine when done right and you have the spare time but should not trump better design or excuse lack of priviledge seperation or the often underused and mis-understood power of DACs not being used to their upmost in the first place. Virtual machines add complexity, waste resources and cannot be on by default for each package which is very important. Also many new attacks like timing attacks between virtual machines arrive. Auditing and bug reporting is also greatly complicated compared to bare metal. I am interested in finding out more about qubes though if I find the time for the desktop, mainly in terms of how deep they may have gone for sandboxing say a browser. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/686939.12569...@smtp141.mail.ir2.yahoo.com
Re: Hardened OpenSSL fork
previously on this list Thomas Goirand contributed: OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g I'm not so sure if cleaning-up really means removing 90k lines of code without extensive checks. I'd very much prefer some unit tests added to the current code base, or a *long* audit process for example. I understand the concern over reliability in the short term but they are not playing and quite frankly in light of heartbleed any issues that align with 99% of use cases can be fixed and I don't think that has anything to do with the OPs thread. If it does what 99% need (you should test in any case) and has 90k less lines of code then the rest can be better audited and if better understood then it is more likely to work especially in the long term, it is not part of OpenBSD stable yet. I guess you haven't witnessed all the examples of code rot and worse that they have found? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/930532.18175...@smtp112.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
On Tue, 29 Apr 2014 00:20:05 + Jacob Appelbaum wrote: Tor provides privacy and more likely lowers security so which threat against contributors or contributor actions is the Tor policy aimed to protect? I'm confused, what? How does Tor lower security and at the same time, it provides privacy? Just like antivirus scanners bring greater exploitability especially if you are not vulnerable to detectable viruses then so does Tor. It adds a lot of complexity for privacy benefit. Integrity is often muddled into security too. As far as I am concerned they can actually counter each other and are seperate entities. Security is an application specific process to be understood in light of a particular threat model. So Tor for certain things yes but not for everything. Obscuring from targetted attack is highly questionable to me when a secure VPN from a lightly used machine (no web browsing) can offer real security. You may just be giving a way in otherwise. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/400899.24381...@smtp140.mail.ir2.yahoo.com
Re: Gcc and undefined behavior
previously on this list Vincent Lefevre contributed: Plus, crashing in a screensaver is bad :D The sanitizers should be used only for testing / debugging, or possibly for critical applications where it may be better to crash (in a controlled way) than behave erratically with possible system compromission as a consequence. I am not sure exactly what checks you are talking about but isn't this debatable in that if it is more likely to crash early or immediately then the bugs are more likely to be fixed and it could have crashed later anyway at a more critical and less analysed time or led to greater consequences or bugs present in more critical deployments. OpenBSD catches many bugs but they are not the size of Debian which could catch more. Perhaps there is an argument just for testing as oppose to stable? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/113866.98512...@smtp113.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
previously on this list Thorsten Glaser contributed: Debian policy should require that in every source package all security packages should be clearly marked as such in standard and easily parsable way with optional further references. Veto because the security impact of bugs is disputable, and probably 100% of all patches: http://www.insanitybit.com/2012/06/02/linus-torvalds-all-bugs-are-created- equal-9/ ? Doesn't that page argue against your 'veto'? I can understand Linus not wanting to have to decide if there is any security relevence in each change or be accused of missing some when he of course would especially when he has said he can't keep up with the many commits and so must want to accelerate and not decelerate the process. I used to look through the commits when I could in order to decide whether to update the kernel more often than every other release and whilst some were obvious or even mentioned security I wondered what level of collaboration went on between distros to work out which had security implications or whether seperate processes helped spot more or not and just created more work. In any case once publicly known and sooner the better it is surely better to inform at every opportunity. p.s. Security is never black and white and I hate the same people, funny that, like reading your stars. There is lots of mis-information and lies about OpenBSD out there. I notice the page doesn't disclose any of his supposed findings or say very much at all. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/406410.91532...@smtp109.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
previously on this list Thorsten Glaser contributed: A wide misconception. Chroots are easily implemented and add security almost for free (often /dev/log is all that is needed) and so can be used by default without any potential problems, they also never bring new risks and always make life difficult for an attacker to raise priviledges or get what they are actually after when done correctly. Even at a simple level it should be obvious that they can just nullify the payload so the attacker simply goes elsewhere. Does Bwahahahahahahahahahahahahahahahahahaha! (To casual observers: the entire paragraph is very wrong.) Yes, chroots help isolating things, but, just like systrace(4), they are far from being inescapable. I also said the following and nothing is inescapable atleast in any general conversation, so who is being black and white now! Chroot provides a noticeable improvement in security at a very low cost in time to implement and almost 0 maintenance. Systrace has security merit too despite it's shortcomings at isolating ROOT in CERTAIN SITUATIONS and is used by sshd now by default. If the kernel can be attacked from the chroot then likely the MAC can and due to increased complexity, arguments just as easily arise against both. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/80183.89090...@smtp103.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
previously on this list Marko Randjelovic contributed: Well, we have the word hardening in the subject, I'm not sure what OP meant, probably he ment more security then hardening, but grsecurity which is mentioned in wiki[1] contains features to prevent breaking out of chroot, so combined with grsecurity chroot might be called a security feature? Fair enough but almost all of those escape mitigations combat an attacker with ROOT priviledges and you shouldn't have been running the daemon as root in the first place and what is not in the chroot makes raising priviledges to root much more difficult. Chroot *IS* a security feature as extensively used by dovecot including priv sep and coded into sshd and unbound and apache and nginx. People *HAVE* watched attackers get frustrated and leave. The first thing an attacker usually tries with an exploit is to load /bin/sh then they may try to get data into the filesystem but find the filesystem is noexec and likely not writable by the process owner. Then all of a sudden especially with ASLR and a nonexec stack things have gotten much more difficult and the chances of causing noticeable crashes increases. At this point if they haven't left already, two things are likely to happen, if it is non targeted as the kernel.org attack was they leave and find one of the many other systems to attack. If it is a buy and shoot attack it has failed to execute the buyers shell code or program and your just one more system that isn't on their botlist. Otherwise they have a more difficult task of exploring the process space and attacking the kernel or hoping the chroot is not owned by root or the cd was not invoked. Chroot also helps to prevent MAC bypass on systems where grsec prvi I/O is not disabled. The whole point is security is layers and in my opinion MAC should be the final layer but many distro's and more so Fedora than debian use it whilst ignoring their lax DAC permissions. I thought this would be a no-brainer default atleast for some packages. I guess I was wrong? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/450827.54193...@smtp120.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
previously on this list Paul Wise contributed: I have written a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and computer systems of the Debian project, contributors and users. https://wiki.debian.org/Hardening/Goals If you have more ideas, please add them to the wiki page. Though it will take some guts, the best way I see for a distro to help users secure their machines is to provide sudoers entries disabled by default and enabled either manually through requests during various package installs or a sudoers-policies package or in sudoers.d by default. I've read a story about sudoers being packaged by distro's at one time but mistakes meaning they stopped doing so. I expect that's a myth and silly if not. I find little about it but hearsay and whilst I know sudo's maintainer prefers rules not to be enabled by default as that encourages general policies and so an insecure default. I am not sure he minds commented policies that are easily enabled. If I ever have any time I intend to create a sudoers policy site if no-one beats me to it and more searches don't find one but a project like debian may be better suited to the task. Sudo is undoubtedly more secure than polkit when used correctly and easily modified by users. If things like synaptic had an option to use sudo, users could very easily and intuitively modify the default policy to only allow a certain list of packages to be installed and synaptic would be none the wiser and work very securely with whatever exact permissions the user decides and that apt-get provides the control for. This empowers users and the more correct way of doing things. Any security related tools and settings should have a high quality man page. All security configuration should be insisted on being in /etc if it isn't already. A default polkit configuration for example should be easily found and edited and not be allowed to exist in /usr or need to be copied from anywhere to anywhere. That is simply irresponsible. sysctl.conf could perhaps have more commented entries If a doc exists in /usr/share then perhaps a man page should atleast point to it and be found via apropos in many cases as understanding is the first step to securing. You could port the privledge seperation patches for X11 from OpenBSD so that only a small part for handling device files etc. runs as root. tcpdump is more secure but for more risky things like wireshark it could be made to die perhaps by a wrapper if run as root and dumpcap be suid group wireshark mode 750 and users add themselves to that group to use it. http://marc.info/?l=openbsd-miscm=139694935227588w=2 More use of chrooting by default would be good too. Some comments on the existing content on the page follows. Tor provides privacy and more likely lowers security so which threat against contributors or contributor actions is the Tor policy aimed to protect? Asking contributor's to boot debian where possible without listening services from dedicated usb/hdd with a vpn or ssh to avoid router resident attackers maybe seen as a bit draconian but I would suggest is a better practice to aim for. If grsec is coming RBAC deserves mentioning under MACs Routers, you could simplify their usage so you are using a subset of the firmware risk. So use bridge mode and a pppoe client on a debian or an OpenBSD box where I can contest pppoe setup is dead easy and in kernel. Though the bastille debian box and VPN two paragraphs up is probably easier for most with wireless etc. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/246269.70707...@smtp101.mail.ir2.yahoo.com
Re: Hardened OpenSSL fork
On Mon, 21 Apr 2014 10:55:36 +0200 Kurt Roeckx wrote: I'm not sure what you're trying to say here. But look at the example of the random number generator in my other e-mail. I've seen other cases were they do things like that. And I can perfectly understand why they do it, and then rely on that behaviour on OpenBSD, but it only works on OpenBSD. It is a big task they are undertaking and are simply making their job easier. Later I expect portability patches can be more easily considered. I am sure OpenBSD get's far less funding than OpenSSL you know. I don't use debian online but if I did I would find an OpenSSL package with a dependence on haveged until something better is upstreamed desirable. I also expect patches may be needed or reverted for OpenBSD's long long time_t. http://www.openbsd.org/papers/eurobsdcon_2013_time_t/ It did because it would have been picked up likely weeks after the bug was introduced due to OpenBSD and Gentoo hardened bug reports or static analysis resulting in bug reports. As Theo says possibly before it was actually released meaning all risk avoided essentially for free. It seems you do not understand either vulnerability. I understand it perfectly, did you follow the link I posted to Theo's response to an OpenSSl dev about this very thing or the slides about OpenBSD's mitigation tecniques. It would have been found sooner or later way before it was. Replacing malloc has been described as exploitaion mitigation mitigation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/214362.32904...@smtp130.mail.ir2.yahoo.com
Re: Proposing amd64-hardened architecture for Debian
together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/931879.29654...@smtp141.mail.ir2.yahoo.com
Re: Hardened OpenSSL fork
previously on this list people contributed: On Sun, Apr 20, 2014 at 07:07:45PM +0100, Steven Chamberlain wrote: Hi, But meanwhile, OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g. One of the problems with anything from OpenBSD is that they only care about OpenBSD, and if you want to use that fork you'll actually have to go and revert some of the things they're doing. Not true actually but of course their primary concern is naturally OpenBSD. They takes POSIX seriously and atleast one patch has brought it closer to POSIX standards. It is also clear to me that Theo wants all to follow and benefit from best practice and bug hunting, the fact that there is so much resistance is not his fault... is strlcpy still rejected by glibc on the false premise of not solving truncation despite better performance than strncpy and when it makes finding truncation much easier! when used how they have been applying it to openssl. https://lwn.net/Articles/507319/ Some of the things they're changing are actually good changes, but some are also just wrong. They don't seem to be understanding why things are the way they are and seem to be changing code they don't understand. Based on what? heartbleed happening due to performance for embedded but there is little need and no need for doing so generically. Sure they are ripping much out and rewriting parts just to get it going on OpenBSD initially with the statement on undeadly that portability can be brought back later. OpenSSH development certainly looks more than co-operative to linux portability. They also seems to like to do white space changes, which is really helpful. Apparently it is to them in following the style(9) they are used to. What's the problem, ignoring whitespace for diffing is easy. It's now using native malloc/free instead of its own allocator which allowed the Heartbleed bug to happen. This did not allow heartbleed to happen. It might have hidden CVE-2010-5298 more, but it was always there and is unrelated to heartbleed. It did because it would have been picked up likely weeks after the bug was introduced due to OpenBSD and Gentoo hardened bug reports or static analysis resulting in bug reports. As Theo says possibly before it was actually released meaning all risk avoided essentially for free. I wonder if this might result in an alternate SSL/TLS library we could use in Debian? There are alternatives, but I guess you mean alternative to openssl. Currently it actually doesn't look like a good option to me. If it is more secure then it meets most users needs better and so I disagree. The suggestion was for another package anyway like OpenNTP which avoided the recent security issues. Of course it is too early for this to be done now and who knows how upstream will react but considering their revenue streams that will likely have a lot to do with damage limitation. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/602746.76025...@smtp109.mail.ir2.yahoo.com
Re: Proposing amd64-hardened architecture for Debian
previously on this list Michael Tautschnig contributed: Riding the Heartbleed publicity wave seems unwise, unless you can propose a hardening flag that would have protected users from Heartbleed. Else, Heartbleed merely serves on a example how wallpapering problems over with hardened binaries often doesn't help you at all.. +100 on this one. Hardening may be nice, but wouldn't have helped at all w.r.t. Heartbleed (or any of the other recent SSL/TLS issues). I am afraid you have this completely backwards. You can't use idiotic programming to justify anything. http://marc.info/?l=openbsd-miscm=139715715931884w=2 I am glad they are cleaning OpenSSL up http://undeadly.org/cgi?action=articlesid=20140418063443 Especially when what they have found is very surprising -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547070.34899...@smtp119.mail.ir2.yahoo.com
Re: Proposing amd64-hardened architecture for Debian
On Fri, 18 Apr 2014 14:57:41 +0200 Aaron Zauner wrote: Usually the Linux kernel itself provides more than enough entropy. This can (and probably should) be enhanced but should not be done in a specific distribution. I know there has been a little work on the kernel in this area, mainly when you have a modern cpu you will be fine but are the days of waiting on gpg and being asked to move the mouse on the latest Linux Kernel and whichever kernel lands in debian 8 over? You should be able to write gigabytes of random data to disk without any worry. Building exploit mitigations isn’t easy. It’s difficult because the attackers are relentlessly clever. And it’s aggravating because there’s so much shitty software that doesn’t run properly even when it’s not under attack, meaning that many mitigations cannot be fully enabled. But it’s absolutely infuriating when developers of security sensitive software are actively thwarting those efforts by using the world’s most exploitable allocation policy and then not even testing that one can disable it. Nothing to add here, very well said! I realised just after sending that I had removed one too many seperating lines (before the link). So I wasn't as clear as I meant to be in that the bit above was taken from an OpenBSD devs (Teds) page about Heartbleed. http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/505473.83266...@smtp146.mail.ir2.yahoo.com
Re: Proposing amd64-hardened architecture for Debian
___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/67745.48677...@smtp129.mail.ir2.yahoo.com
Re: the importance of defaults (was: Debian default desktop environment)
previously on this list Cesare Leonardi contributed: On 12/04/2014 12:23, alberto fuentes wrote: While i like Xfce, my current DE, the thing i worry most is that it seems almost stagnant: the latest release (4.10) was from 2 years ago and from the Xfce main site and blog i see no advancements. Really really a pity. 4.11 is downloadable actually, xfce follows a stable philosophy like debian does. You should also compare like for like, 4.11 or 4.10 to mate as debian stables (itself old) packages are far older than two years. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/619137.17007...@smtp108.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list people contributed: but that doesn't change the fact that ffm with autoraise works in gnome3. GNOME 3 is based on Mutter which has, AFAICT, all features Metacity (GNOME 2) used to provide. The focus settings are not shown in the control center, but you can use gnome-tweak-tool or the gsettings CLI to change them. Last time I looked it was alledged but no raise on click was not offered and couldn't be manually done. The main problem in GNOME 3.4 with focus-follows-mouse is that it makes the application menu (in the top bar) mostly unusable if you have to move the pointer over another application to reach the menu. But the application menu is not used much in 3.4, and the problem should be fixed in more recent versions (the application menu doesn’t switch immediately with the focus). You can change the timing on xfce, inherited from the brill fvwm and also the timing of desktop scroll by mouse. I am getting the impression that many missed a detail. It also supports focus follows mouse, no raise on click ^^ I am talking about focus follows mouse but raise only on clicking say the border or bar, you can still enter text into any layered windows that have focus. So you can quickly switch for entry to or from web pages on one screen or read a web page in the background. Reference 4 open windows at once, use the scroll upon focus etc.. Basically the closest thing to a panelling window manager like scrotwm (which I could learn) without needing to learn the commands (works for my users too and I should test what I provide) and allowing overlapping for redundant web edges, saves time re-sizing etc.. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/821760.5213...@smtp138.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list Bálint Réczey contributed: Xfce is friendly enough, but it feels old compared to Gnome 3 and I would like to attract new users before convincing them. It is much easier than in the opposite order. :-) I think you are reflecting a subset of users priorities. I've switched users from desktop to desktop and they don't care a jot about flashiness in fact many like simple but pretty which is perfectly do-able with almost any window manager, what they hate is a) things moving too much that they can't find b) not being able to do what they want or things disappearing Looking Flashy is always enticing but not at any functional expense and limited performance expense. Gnome 3 is getting both a and b wrong. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/317873.5213...@smtp138.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list Jean-Christophe Dubacq contributed: I am talking about focus follows mouse but raise only on clicking say the border or bar, you can still enter text into any layered windows that have focus. So you can quickly switch for entry to or from web pages on one screen or read a web page in the background. Reference 4 open windows at once, use the scroll upon focus etc.. Basically the closest thing to a panelling window manager like scrotwm (which I could learn) without needing to learn the commands (works for my users too and I should test what I provide) and allowing overlapping for redundant web edges, saves time re-sizing etc.. And this is a so tiny detail that it does not matter for what should be the default desktop environment. No matter how configurable is your thing, what matters is how usable is it out of the box. ??? I agree with someone else who responded with killer feature as for me it is also a primary requirement from a window manager precisely because of the usability increase. For the rest, apt-get or any other package management interface is your friend. Exactly, This all came from xfce multiple desktop support in debian 8 apparently not being the best, I was merely saying that it matters less to xfce because of this feature but also with *randr from apt-get it is not a problem and later versions than xfce-display-settings-4.10 I am pretty sure do have good support without *randr bootstrapping. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/852276.47110...@smtp141.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list Iain R. Learmonth contributed: The problem of integration is present, but now that I think about it, is likely more of an upstream problem than a packaging problem. I guess as more and more things use dbus, integration will become easier. Perhaps but integration and universal interfacing is more of a design issue and you could in many cases argue that dbus makes this worse through adding an extra potentially non universal interface especially for servers. The job of dbus is for universal sockets and making life easier for programmers that need that in handling the protocol for them and shouldn't be thought of as anything magic or to promote good design. It can make things cryptic to users and more effort to get a handle on for users for a start. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/581286.94347...@smtp115.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list Wookey contributed: but I just wanted to repoy to correct the apparent misapprehension that XFCE doesn't do user-friendly monitor out of the box. It is hardly a showstopper either and I expect xfce-4.10 does and as there has been a long time of testing before 4.10 was released as stable it is put at a bit of a disadvantage to Gnome and KDE for having the same aims as debian stable with the bugs I have come across such as in mimecache handling actually being down to gnome libraries. As already said the control of this is very simple via *randr. It also supports focus follows mouse, no raise on click which is something inherited from fvwm and Gnome cannot do even with gnome tweaks last time I checked and KDE had a bug open about it. I find that very useful to make the most of even multiple desktops and more would use it if they could. Atleast with 'win98' (rediculous and no reply to justify so far) you won't suddenly have users not knowing how to shutdown their machine like happened on was it win 8 and Gnome 3. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/35081.94347...@smtp115.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list Adam D. Barratt contributed: Please fix your clock. Have you considered relying on your own clock? I use mail receive order. Do you not get spam annoyingly staying at the top of your box? Sorry if your client does not allow that or doesn't support maildir but this is a linux box that I haven't had time to upgrade but I shall be moving back to OpenBSD as soon as the new webkit packages hit the mirrors (few days max most likely). On linux if the clock has been set forward by accident then it stupidly requires root to do a manual fsck and which I can't be bothered with hence since yesterday currently always going forward, still can't find reverse. Let's not bring up ntp, crappy bios (not crystal) etc. etc.. Regards Kc -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/487717.67707...@smtp135.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list Jakub Wilk contributed: * Gunnar Wolf gw...@gwolf.org, 2014-04-04, 23:22: - Media player: mplayer (on libcaca, of course) With its 4 RC bugs, it doesn't look like mplayer is going to be part of jessie. I can't tell, is that sarcasm, I hope so as it is the only player hat does certain things or has enough performance for some video on some machines. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/212583.85816...@smtp139.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list Philip Hands contributed: As for my grumpy tone, I apologise for that -- it probably comes from the several voluminous threads on debian-devel recently spouting drivel about systemd which I may have unfairly associated with this thread. If you think it's all drivel then I would suggest you do not understand the issues raised or the opposing points of view of many. https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU p.s. If you read far enough then please ignore the part about sudo being coarse grained as it allows a far more fine grained approach than the defaults of polkit and the rediculous pkexec with great intuitive power to the user too. In any other case proper specific priv sep should be used anyway. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/717862.61818...@smtp102.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list Undefined User contributed: It's not about Gnome, Xfce or whatever desktop environment being focused only on touchscreen devices or identical to a mobile platform (that would be terrible for everyone), but at least something that doesn't make people think that Debian looks like from last decade and don't support new technologies (although, we all know, none of these being true -- but we have to show it). I'm not sure I agree or that many care so much. In just the last few weeks I have had one 80 year old and one 30 year old both say they wanted the Windows XP interface back over Windows 7/Vista repectively. Which bit exactly do you think looks like win 98? xfce4-panel; gnome-panel runs in xfce. It should take very little to improve the look of xfce and with very little memory usage increase. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/237840.89367...@smtp101.mail.ir2.yahoo.com
Re: Debian default desktop environment
previously on this list people contributed: Why then install an alternative at all. Experienced users install what they want anyways. The DEs working best for unexperienced users would be the DEs that do much work themselves, Xfce allows more options and choice by default on a cd and unexperienced users have a better chance of loading synaptic and a web browser on xfce than heavier desktops and is meant to be more stable. Hasn't Gnome or just GTK3? just removed cue tips shortcuts too affecting mouse/touchless systems. XFCE (at least the version in Debian 8) doesn't automatically handle external monitors, which is a pretty significant use-case for all kinds of users. I don't want to reboot right now but xfce4-display-settings in debian 7 does atleast after you have run xrandr and I would guess if plugged in during boot up as my second screen comes up by itself with it's own panels when it is. I do not think it's fair to expect a new user to be configure xrandr or find install a 3rd party xrandr GUI. You could add lxrandr to the default and the DE would still be smaller than gnome. How modular is Gnome, you could even use their display management tools until newer versions of xfce hit debian stable, atleast you should be able to? I know xfce 4.11 might take some time to hit stable and has some extra tweaks such as for having screens above and below each other. Perhaps having an xfce backports choice during install is another idea but I guess that couldn't be supported. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/615301.77533...@smtp118.mail.ir2.yahoo.com
Re: ca-certificates: no more cacert.org certificates?!?
previously on this list Bas Wijnen contributed: On Tue, Apr 01, 2014 at 10:49:15PM +0100, Kevin Chadwick wrote: I think at Debian we all agree that it would be a good thing if everything would be encrypted, so this is a very bad outcome. I beg to differ I'm afraid. SSL should be used where it is required otherwise you are opening the server upto DOS and as it is more complex, bugs and exploits not to mention greater memory and cpu usage in similar fashion to systemd. That's a valid point. I think all connections should be encrypted, unless the server admin knowingly disables the encryption. Does that sound better? What I would like to see, is that if someone new to making websites tries something, they will be using encrypted connections. And if they start asking people to fill out personal data, they don't need to do anything extra to make sure it works right. Sorry but I still have to disagree as this shouldn't really but certainly does still increase the chances of someone submitting data to a site that doesn't care about the security of that data or have the ability to look after it. OTOH it would prevent wordpress logins being stolen so easily and ISPs snooping, however I believe in solving specific problems not swapping problems around, what do you know again like systemd due to it's multi functional design or rather lack of it;-) -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/991243.53700...@smtp120.mail.ir2.yahoo.com
Re: default messaging/VoIP client for Debian 8/Jessie
previously on this list Russ Allbery contributed: I guess you missed all the exploits in JAVA over the years and especially last year where it was banned for long periods from all browsers. To the point that the pressure is building on web hosts to drop JAVA KVM clients completely. Most of the exploits in Java (I have no idea why you write the word in all caps) Just from the logo, the one I see on Windows boxes as I don't really see one anywhere else and avoid it wherever possible and which is the correct stance to take for multiple reasons. http://blog.trendmicro.com/trendlabs-security-intelligence/java-native-layer-exploits-going-up/ are flaws in the sandbox security model. While those are real vulnerabilities in the context of running untrusted Java applets downloaded from the network, they're not horribly interesting in the context of running trusted applications installed through normal signed apt repositories. Not horribly interesting isn't saying much and the rediculous number of vulns on osvdb this year alone not to mention the bloatedness and ability to run jars in such a complex beast outside the unix security model by default is more than enough to rule out any default java apps in I'm sure many peoples opinion. Heck CESG guidelines say to get rid of small parsers like perl and shell access. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/676094.53700...@smtp120.mail.ir2.yahoo.com
Re: systemd and Linux are *fundamentally incompatible* - and I can prove it
previously on this list Jan Gloser contributed: Kev, the systemd design document says it all about the lack of design with statements showing a clear lack of understanding. I would be ashamed to call it a design document. I would also like to ask something the people who dislike systemd (as there seem to be more). I am not very proficient with such internals of debian, but you say things like systemd breaks things and systemd has no unified design and sytemd is possibly a security risk. But can you give some easily reproducible examples or setups, code samples, cucumber scenarios, whatever, that could clearly demonstrate how systemd breaks anything? As systemd tries to do so much it is pointless as you simply get side tracked when your arguments succeed or ironically get called trolls by real trolls. I will just say this OpenBSDs /sbin/init.c is 1448 lines long Systemds rediculously placed /usr/lib/systemd/systemd.c doesn't exist but rather there is a directory with many files and just cgroup.c is nearly 1000 lines long. So good luck evaluating all of that for your next linux based system when quite clearly the devs don't know even pid1 like the back of their hand due to having a segfault rather than die in it. pid1 being potentially larger than your daemon would be quite laughable too. As even well audited code tends to have a bug per 1000 lines, is having this much code permanently resident supposedly for all of Linux never mind unix ecosystems that have served each other so well a good design especially when linux is moving onto smaller and smaller devices? Are the benefits worth it? Is it self managing and open to competition. It is difficult to get a good design from a bad design. Evolving /sbin/init simple functionality in the past resulted in migration of code into the kernel and not the other way around. Such a fundamental game changer with so much clouding the core functionality in terms of pulling in so much really shouldn't be decided by a 50/50 decision. Companies often require 75% or more for game changing decisions. scenario, why not just migrate to Gentoo or BSD? Gentoo means you have to build otherwise I would for the few things I need linux for. Sabayon has moved to systemd and my system would have broken recently because of systemd if I was using it. I use OpenBSD wherever possible. Things are often tested on debian or *buntu and the base is well tested and hence my usage for offline development. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/216266.53700...@smtp120.mail.ir2.yahoo.com
Re: systemd and Linux are *fundamentally incompatible* - and I can prove it
previously on this list The Wanderer contributed: I was explicitly referring to the point in the future when maintainers do stop providing traditional init scripts. This likely won't happen that fast, no, but I do think it's likely that it will happen - whether days after the jessie release or decades, or more likely something in between. You know that's what Arch Linux devs said two months before banishing init scripts to AUR where it wasn't even gpg signed. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/695583.53700...@smtp120.mail.ir2.yahoo.com
Re: systemd - some more considerations
previously on this list Matthias Urlichs contributed: I don't believe I have said that. «die» is not the same as «crash». If you're talking about PID1, the end result is the same. It is not because one is a foreseen issue and the other indicates a lack of polish on PID1! -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/199497.53700...@smtp120.mail.ir2.yahoo.com
Re: systemd - some more considerations
previously on this list Steve Langasek contributed: The avalanche has already started; it is too late for the pebbles to vote. Winston Churchill said It is never too late a few times and I think some of his quotes are quite fitting. A lie gets halfway around the world before the truth has a chance to get its pants on. Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing has happened. You have enemies? Good. That means you´ve stood up for something, sometime in your life. It has been said that democracy is the worst form of government except all the others that have been tried. Never give in-never, never, never, never, in nothing great or small, large or petty, never give in except to convictions of honour and good sense. Never yield to force; never yield to the apparently overwhelming might of the enemy. And one that's funny to lighten the mood. Lady Astor: Winston, if I were your wife I´d put poison in your coffee. Winston Churchill: Nancy, if I were your husband I´d drink it. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/679110.53700...@smtp120.mail.ir2.yahoo.com
Re: ca-certificates: no more cacert.org certificates?!?
previously on this list people contributed: I still don't see why we penalize Debian users for the fact that _other_ operating systems don't include the cacert certificate Seems illogical to me we need more free CAs not less and I do agree about the extortionism especially on EV. If a web designer only tests if one browser works on one OS without a chaining issue then does he really care and is he a fool that needs teaching anyhow. I have to agree on that. But a Startcom Certificate on a personal web site is one web site more that doesn't train users to blindly click away certificate warnings. A cacert certificate or a self-signed certificate on a personal web site is one web site more that does that kind of training. Or to check if they are on the right domain? Xombrero caching of cert changes and warnings is useful in the terrible climate for those who know what to check. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/169118.38101...@smtp132.mail.ir2.yahoo.com
Re: default messaging/VoIP client for Debian 8/Jessie
previously on this list Bas Wijnen contributed: I see the problem of all the bloat that comes with Java, but it is minor. The main problem is still https://www.gnu.org/philosophy/java-trap.html I guess you missed all the exploits in JAVA over the years and especially last year where it was banned for long periods from all browsers. To the point that the pressure is building on web hosts to drop JAVA KVM clients completely. I'm starting to question if Debian takes security and correctness seriously enough. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/92558.69695...@smtp146.mail.ir2.yahoo.com
Re: ca-certificates: no more cacert.org certificates?!?
previously on this list Bas Wijnen contributed: From: Bas Wijnen wij...@debian.org To: debian-devel@lists.debian.org Subject: Re: ca-certificates: no more cacert.org certificates?!? Date: Tue, 1 Apr 2014 22:22:12 +0200 User-Agent: Mutt/1.5.21 (2010-09-15) On Tue, Apr 01, 2014 at 11:04:43AM +0100, Philip Hands wrote: I think the real problem here is the user interface asking one to trust a site (forever, unless you're concentrating) at a point where you really don't care because all you're interested in is seeing the cute picture of an otter on someone's blog. Yes. And the fact that making your blog use an encrypted connection causes either scary warnings for all your visitors, or a lot of hassle trying to find a CA who is slightly less extorting than the others, leads to the result that most people give it up and don't use encryption on their blog. I agree I think at Debian we all agree that it would be a good thing if everything would be encrypted, so this is a very bad outcome. I beg to differ I'm afraid. SSL should be used where it is required otherwise you are opening the server upto DOS and as it is more complex, bugs and exploits not to mention greater memory and cpu usage in similar fashion to systemd. I've also asked Mozilla to give plain HTTP connections at least as much warnings as self-signed certificates (which would probably mean no warnings for either of them), but I don't think they'll listen. What have you asked them exactly. I believe glaring warnings should be removed from self-signed and green bars removed completely for EV certs but you should be asked to check the fingerprint for self-signed and the browser should cache the cert and warn of changes in all cases though that would scare the uninitiated at first??? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/616880.64104...@smtp144.mail.ir2.yahoo.com
Re: default messaging/VoIP client for Debian 8/Jessie
I use JAVA for eclipse (mostly good but a bit of a pain at times but I need a particular plugin for embedded work, commercial prog dependence in other cases) but think JAVA by default would be a big negative even aside from being a dpig, especially for anything network facing and especially without config lock down. Does it require the web plugin? p.s. I've been waiting/hoping to get a proper *nix/nux on my phone but do any of them work with Android and Iphone as they are a bit pointless without friends and I don't like whatsapp as it's made my phone act a bit funny and has eaten up valuable memory. Tox has been mentioned on the OpenBSD ports list recently which got my attention and has a pidgin plugin and android client but I think you would need ekiga/asterisk for sip and it's stated as not 'complete' yet too. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/481258.86380...@smtp150.mail.ir2.yahoo.com
Re: systemd and Linux are *fundamentally incompatible* - and I can prove it
previously on this list Brett Parker contributed: Maybe you should do some more investigation, get some better clue of what you're talking about, and come back with a better, more thought out, set of arguments that actually have merit. Right, by arguing on the basis of the definition of Linux rather than the meaning of his arguments, or as often is the case on this subject dividing and conquering or ignoring the valid points and changing the subject to the 100th *needed* functionality that every system apparently should have by default but actually turns out to already exist but optionally installed and actually means little or just gets in the way of better implementations. There is another reason why Unix consisting of parts that do one thing well is so valuable and that is because arguing over the best way of doing it can't be polluted or crap forced in the back door with the good. Your response is actually closer to trolling. Why is it the the word troll gets so abused. Naming people trolls when they are not is worse than trolling in my opinion. I really haven't the time right now to look over the links having took a break from work to watch a footy match but assuming I didn't miss the sarcasm then if Thorsten Glazer sees even an ounce of merit then I can almost guarantee he is not trolling. p.s. systemd being a bad design for an OS which aims to be so cross platform is simply obvious to me on many levels, at the very least it calls for extra oil/work/code depending on the scenario to meet that aim and with little/no *real/truly beneficial* reason. Still maybe it will be the death of Linux on the desktop atleast for techies and I wouldn't mind to be honest as without grsecurity the linux *kernel* actually has less security features than Windows or even FreeBSD now and FreeBSD was trailing behind for a long time. The userland security is much better than windows but with the exception of apt repos being the only well used thing that springs to mind (which is a valuable security feature) this was basically inherited from good designers. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/815696.92264...@smtp145.mail.ir2.yahoo.com
Re: Bits from the Security Team
previously on this list Matthias Urlichs contributed: I did a „setcap cap_sys_ptrace+eip /usr/lib/nagios/plugins/check_procs”, but a normal user can’t still check for running programs of another user. What did I wrong? check_procs is a script, not a real executable. Since starting an interpreter with capabilities (or setuid, for that matter) of a script involves a race condition (kernel starts interpreter with script's rights, Joe Badass replaces the script with something Is it writable by others than root? I don't know the details of hidepid but the grsecurity patch has similar? functionality and lets users see their own processes or a group see them all. +menu Filesystem Protections +depends on GRKERNSEC + +config GRKERNSEC_PROC + bool Proc restrictions + help + If you say Y here, the permissions of the /proc filesystem + will be altered to enhance system security and privacy. You MUST + choose either a user only restriction or a user and group restriction. + Depending upon the option you choose, you can either restrict users to + see only the processes they themselves run, or choose a group that can + view all processes and files normally restricted to root if you choose + the restrict to user only option. NOTE: If you're running identd or + ntpd as a non-root user, you will have to run it as the group you + specify here. + +config GRKERNSEC_PROC_USER + bool Restrict /proc to user only + depends on GRKERNSEC_PROC + help + If you say Y here, non-root users will only be able to view their own + processes, and restricts them from viewing network-related information, + and viewing kernel symbol and module information. + +config GRKERNSEC_PROC_USERGROUP + bool Allow special group + depends on GRKERNSEC_PROC !GRKERNSEC_PROC_USER + help + If you say Y here, you will be able to select a group that will be + able to view all processes and network-related information. If you've + enabled GRKERNSEC_HIDESYM, kernel and symbol information may still + remain hidden. This option is useful if you want to run identd as + a non-root user. + +config GRKERNSEC_PROC_GID + int GID for special group + depends on GRKERNSEC_PROC_USERGROUP + default 1001 + +config GRKERNSEC_PROC_ADD + bool Additional restrictions + depends on GRKERNSEC_PROC_USER || GRKERNSEC_PROC_USERGROUP + help + If you say Y here, additional restrictions will be placed on + /proc that keep normal users from viewing device information and + slabinfo information that could be useful for exploits. + +config GRKERNSEC_LINK + bool Linking restrictions + help + If you say Y here, /tmp race exploits will be prevented, since users + will no longer be able to follow symlinks owned by other users in + world-writable +t directories (e.g. /tmp), unless the owner of the + symlink is the owner of the directory. users will also not be + able to hardlink to files they do not own. If the sysctl option is + enabled, a sysctl option with name linking_restrictions is created. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/64312.74336...@smtp121.mail.ir2.yahoo.com
Re: default init on non-Linux platforms
previously on this list Matthias Urlichs contributed: Kevin, I don't think you understand the reasoning behind this. Again, the problem the init system has to solve here is being able to track a process with a 100% accuracy, so whatever automated mechanisms you have configured when certain situations occur, they have to find the correct process to work on as to not kill the daemon instance you actually still need. … not to mention any other processes which the daemon started, which may or may not linger after its (grand)parent died, and which may or may not cause problems when restarting. Never happened to me and shouldn't happen on a well designed service that should be controlling it's children. If it does happen you should be checking the system over anyway and possibly filing a bug. The only time I've had zombies is on a desktop. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/706169.64541...@smtp137.mail.ir2.yahoo.com
Re: default init on non-Linux platforms
On Fri, 21 Feb 2014 23:53:51 +0100 John Paul Adrian Glaubitz wrote: Kevin, I don't think you understand the reasoning behind this. Again, the problem the init system has to solve here is being able to track a process with a 100% accuracy, so whatever automated mechanisms you have configured when certain situations occur, they have to find the correct process to work on as to not kill the daemon instance you actually still need. ADRIAN, I hate it when people use your name thinking it makes any difference to the content your about to spout. And, to my current knowledge, this is not possible without a mechanism like CGroups. Whether you rely on PID files or grep through the output of ps or use pidof, either of them are fragile and prone to fail. Regex works just fine for me. I elaborated in my actual real-life case how PID files are prone to failure - I am aware that the situation with the full filesystem shouldn't occur in the first place, Right including the rest of this email that's two counts of fantasy or bad practice now justifying increased complexity in the kernel. but, well administrators are just humans after all - and, using ps to track the process you are looking for to be able to restart, stop or kill it, can obviously be easily tricked into failure as well. I was merely expressing that I think that CGroups are an indispensable if you're planning to use Debian to build modern productive systems with high availability in mind. As I have already said in previous threads that you have obviously forgotten from months ago. Something like CARP for complete server redundancy or Ciscos redundancy protocol, I forget what it is called is the way to go for many reasons. Just imagine some other (malicious) process using the same name as well or when you need to control different instances of the very same process. So you keep machines that are running malicious processes online by adding complexity to the kernel. It is people like you that meant that kernel.org was offline for months after rediculously simple measures weren't bothered with. If you are lucky enough to have malicious processes that can be found rather than a rootkit then you should be pulling the plug investigating and hardening before all your machines take part in a DDOS. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/648730.64541...@smtp137.mail.ir2.yahoo.com
Re: default init on non-Linux platforms
previously on this list Marco d'Itri contributed: But you aren't planning on running openrc at all, are you? Who is? Seriously, would you mind stepping forward? If it was available I would use it but wouldn't be switching cgroups on or would be switching them off even if I hadn't bothered to compile them out of the kernel out of principle and to catch any nonsense that *required* them because some daemon writer has now decided they don't need to bother with tracking their own children anymore. When I used OpenRC on Alpine Linux I found it far nicer to work with than any of systemd, upstart or syv-rc. The only one I find nicer to work with is OpenBSD's. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/277875.64541...@smtp137.mail.ir2.yahoo.com
Re: default init on non-Linux platforms
Perhaps before this thread spirals out of control I should re-iterate that what I said was cgroups doesn't pass the worth-it barrier for me and not that they have NO value. I also mentioned pgroups for those that do want this functionality but also want portability and not bugs in daemons on one system but not another increasing forking, reducing eyefall, collaboration etc. and perhaps want a simpler solution. The benefit that Linux and even firefox etc. has gained from OpenBSD's practically paranoid bug fixing as well as finding the bugs for all the platforms it's userland still runs on especially in compiler tools should be realised and not underestimated. To some degree it will be true for debians HURD and is it kfreebsd too. So I don't get the holding Linux back rubbish especially when it is often based on superficial arguments that carry little weight, atleast in my eyes. Isolating Linux would hold it back and make it a flakier system in my eyes. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/924308.73795...@smtp129.mail.ir2.yahoo.com
Re: default init on non-Linux platforms
previously on this list Kevin Chadwick contributed: Perhaps before this thread spirals out of control I should should also mention this has been discussed on this very list already, though before I was enrolled and the following response went unreplied to. On the other hand and I doubt of significance to me but it may well be worth looking into how Google uses cgroups though apparently systemd causes or would cause problems for them in potential kernel changes being incompatible with their usage. May have been resolved and brought up before though I forget if replied to, but might provide some pro argument for the cgroups case for the few that it matters to rather than the many that enforcing it's usage matters to. https://lists.debian.org/debian-devel/2011/07/msg00423.html ___ It seems this problem (double fork) is the basement of using cgroup under systemd ;) I think messing around with cgroups is a ridiculous way to solve this problem. To be fair, systemd also uses cgroups to reliably kill rogue child processes when stopping a service. This is not unlike what BSD-derived shells use pgroups for, I believe. The right answer is simply to change the daemons to give them an option which causes them not to fork. Then you can just have a single supervision daemon which reaps (and restarts, if desired). I haven't done a survey of the available init replacements but this is not a new concept Well, it's already present in SV init : 1:2345:respawn:/sbin/getty 38400 tty1 and I hope that most of them implement it as a possibility. Daemontools, runit, minit, upstart, systemd all do. I don't know about initng. -- Juliusz -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/489578.4170...@smtp104.mail.ir2.yahoo.com
Re: default init on non-Linux platforms
previously on this list Matthias Urlichs contributed: One sample usecase where they dont't: the system is wedged / overcommitted and I need to terminate some services; guess I'll start another ten processes to do that. Yeah, right. I'll be nice to everybody else here and not enumerate any others. Again that means your system is badly designed or administered without proper restraints such as nice and limits which are important for other reasons. Pkill root owned processes are hardly demanding but quite the opposite. not-well designed services should be fixed. Why should I HAVE to have any evil when I don't have ANY need for it and have much more important things depending on the kernel to be secure. unfortunately cgroups are a necessary evil - Linus Torvalds Should have added for a select few and others that don't know what they are doing! -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/400062.71270...@smtp120.mail.ir2.yahoo.com
Re: default init on non-Linux platforms
previously on this list hero...@gentoo.org contributed: And grepping through the output of ps or similar is not what I would consider reliable and robust either. Nod. grepping `ps` is what we should avoid at all cost. All cost? While I like OpenRC and thanks to Gentoo for it and like your mention of each to there own (I am no old-nerd by the way). I have to disagree. If a service fails I am more interested in why and what will happen if it restarts and not is it back-up already. For that, I would use redundant servers which in any way you look at it and especially for high availability situations must be more reliable than trying to restart a failed service blindly that may not operate as it should when it does. Functional externally generated tests like https returned this file are most valuable for monitoring services and I don't really see your point or the major benefit at all, especially if it involves increased kernel complexity. cgroups doesn't break that, worth it, question for me personally. However whilst I have found the reasoning by the CTTE to have been rather disappointing and superficial and I am unlikely to ever use systemd due to having fundamental issues with it. If a major concern was portability and many of you have your heart set on systemd then although it goes against my desires and technical concerns then perhaps pgroups are worth a mention. http://marc.info/?l=openbsd-miscm=135313692911156w=2 how can someone write this and not explain why a process managing pgroups can't achieve the same results? pgroups is going to be the first alternative for someone instinctively looking for a portable alternative, so i'm genuinely interested in knowing why they've discarded the idea i am, however, aware of differences *unrelated* to writing a systemd like appliance. pgroups do not provide per item hostname and other virtualization facilities in freebsd jails/linux cgroups, but what about *relevant* differences? something weak like the index for for cgroups is wide enough to fit an UUID? in other words, something that *doesn't* require a completely new api? http://marc.info/?l=openbsd-miscm=135314269712851w=2 therefore the requirement for cgroups is completely arbitrary also of interest: * early versions of systemd documentation advised daemon authors not to double fork. presumably cgroups wasn't in the radar at the time * several (all?) openbsd daemons have options for not double-forking. some of these daemons have the gall of preceding systemd -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/163088.43505...@smtp102.mail.ir2.yahoo.com
Re: default init on non-Linux platforms
previously on this list Thomas Goirand contributed: So, systemd is still using /etc/rc?.d. Could you tell exactly what it uses out of /etc/rc?.d, and what for? Does it only needs to see them as S??script-name in runlevel 2 or 4 (or whatever it uses...)? If systemd needs links in /etc/rcX.d, then I think it should be possible to hack something. One of the main things I like about OpenRC and especially OpenBSDs rc system is that you can modify the files directly intuitively. The main thing I hate about the current system is those links and them requiring a tool to edit them in any timely fashion. Almost as much as the huge commandlines needed to do so for systemd without it's tools or for things it's tools can't or couldn't do at the time I tested it out, if I remember rightly to do with org.??? lines. Do people use all those runlevels? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/494637.19636...@smtp114.mail.ir2.yahoo.com
Re: systemd's journal
previously on this list Helmut Grohne contributed: It's just occurred to me that the binary format may not work with append only logging? That's true for the journal. When the journal opens its binary log, it flags the file as being opened, but what is the issue with not being append only? I like to use the kernel to enforce append only on certain log files so that they can't be tampered without finding a kernel exploit or rebooting. Your right in that it does mean you can't compress but I find logs are small on modern disks. I do it all the time on OpenBSD with schg backed up by it's ace critical bug free kernel and have done so on Linux with chattr -a mixed with another trick that I forget right now though I believe it can be done with RBACs like grsecurities or SELinux. Also recovering those logs from a possibly intentionally uncompletely wiped disk would be much harder especially on an ext3/ext4 filesystem where carving is required when otherwise you could image or ddrescue in case of hardware failure and use grep. I have not tried, but I imagine it not being that much harder for the following reasons: If your journal is compressed, you basically lose, but that is true for compressed text logs as well. So if you need this recovery scenario, don't compress. If your journal is uncompressed, you can exploit aspects of the format to find the log. Specifically, log entry consists of key-value pairs, most of which likely match /\(_SYSTEMD_[A-Z_]*\|MESSAGE\)=.*/. Another True and fair enough, though can you read partial fragments from a journal or does it need the whole thing or complete chunks recovered. Anyway it's not like I have ever needed to do this but it's good to know you can and for the same reason I save my odt files as text occasionally when writing them as a more reliable format and advise others to do so. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/889772.23942...@smtp150.mail.ir2.yahoo.com
Re: pulseaudio related problems....
previously on this list Steve Langasek contributed: All software has bugs. The difference is in how you handle them. And how many!!! AND how many per 1000 lines AND how many run with priviledges. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/421905.41062...@smtp141.mail.ir2.yahoo.com
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
previously on this list Matthias Urlichs contributed: discussion. No, we should not depend on it for Debian; but we should provide the interface for system administrators who wish to use it, because it is not Debian's place to tell them that they cannot use that interface. It's not our place to tell people that they _cannot_ use it, but it's a good place to add a consider writing a .service file if you start daemons here; read the XXX manpages to learn more. I agree but more than that why should I waste my time, I have no intention of ever writing a .service file or anything much longer than one-liners else I'd say that something is wrong in one of a few places and most likely the program design. I get the plus of my scripts running on any system, even Windows or a c loop embedded device. Plus I stop services with the likes of pkill as when service stop fails I would prefer to know how anyway and can use them on any system or with any favourite of myself or others whether it's monit, nagios etc. etc. or any shell. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/879291.41062...@smtp141.mail.ir2.yahoo.com
Re: pulseaudio related problems....
previously on this list John Paul Adrian Glaubitz contributed: The problem is that many people who complain about PulseAudio issues are often prejudiced about it in the first place such that they aren't actually interested in having the problem fixed but rather just want to get rid of it and uninstall it. Trying to debug the problem in such cases is very difficult. And to the extent that Debian users are unhappy with pulseaudio as a default, it's because others have been trying to blame the user for the problems instead of constructively engaging to *fix* pulseaudio. I think the reservations are mutual. If your attention as a user is I'm too lazy to take a second to look into how PulseAudio actually works and what box I have to check., you can't expect us on the other side to be happy to help as well. What's that phrase about assumption again? ;-) I'm sure Salvo has, but it is worth checking the PCM in the mixer as it kept being set occasionally to 0 for me on multiple mythbuntu boxes. Though if you don't need the features and don't have the time to set up jackd then why not remove. I assume pulseaudio as the default has some ease of use advantage or feature though as I know jackd is better for pro audio. It hasn't happened since I removed pulseaudio but I did that because it wanted polkit or dbus system-services and without polkit permissions or dbus system-services enabled sound didn't work anyway. I was rather glad when I found adding myself to the audio group meant I got Alsa audio back. Not sure why the audio group was empty by default, surely it should fall back to Alsa? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/31542.41062...@smtp141.mail.ir2.yahoo.com
Re: systemd's journal
previously on this list Helmut Grohne contributed: So for the time being (i.e. until all of my systems and recovery systems are converted to systemd), I do see a slight[2] disadvantage It may take even longer until all initramfs will use systemd (and I do want to read logs from the initramfs if all I can mount is the /var/log). It's just occurred to me that the binary format may not work with append only logging? Also recovering those logs from a possibly intentionally uncompletely wiped disk would be much harder especially on an ext3/ext4 filesystem where carving is required when otherwise you could image or ddrescue in case of hardware failure and use grep. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/327685.41062...@smtp141.mail.ir2.yahoo.com
Re: Honestly, fork systemd
previously on this list Svante Signell contributed: To answer the original poster's own question, what can he do? He can stop writing these emails and start writing code (a fork of systemd supporting kFreeBSD, to be specific) I don't think forking systemd is a good choice, that software id doomed, better to fork gnome components to make them usable with another init system. There are a number of usable components of gnome, e.g. evolution, I would like to still use it, without systemed, but that is currently not possible :( 3.10.4 runs on OpenBSD likely after patching though I don't see any patches to evolution itself in their ports tree. I think Antonio patched OpenBSD's sndio in for pulseaudio for gnome 3. You could look into that. I do see a configure arg --with-sub-version=OpenBSD Ports so maybe the patches were accepted upstream. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527874.41062...@smtp141.mail.ir2.yahoo.com
Re: Honestly, f__k systemd and f__k lennart, and f__k the fans of them. Where's linus in all of this?
previously on this list Gunnar Wolf contributed: Everyone knows that the systemd crap is armtwisting and trys to pull everyone and everything along with it. Please provide some numbers on this statement of fact. I believe (and will continue to believe) that the strong supporters of sysvinit within the development community of debian is a small minority, That IS twisting things in true pro systemd style. SysV fanboys?, I hate SysV but like a small init and yes scripted bootup and certain features like written order of execution in depend lines are way overstated as musts but I have little issue with it. respect and trust those four people - As well as the four others TC members. I haven't had any time yet for looking into the decision process so this may not be the case but (and considering the subject lines I noticed on the ctte mailing list along the lines of voting to avoid systemd) considering the vast implementation difference between all the systems on the table and systemd. It would seem wrong (again this is before I've found time in looking at the details of the members reasoning) to outright consider 4 for systemd against 4 for the others as a decision in favour of systemd? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/358883.76883...@smtp128.mail.ir2.yahoo.com
Re: when will we finally throw away binary uploads (Re: Please upgrade your build environment when you are affected by transition
previously on this list Brian May contributed: After the damage is done, probably easier to find the malware that did it Assuming the damage is visible? All rants aside, I believe there's a fairly wide agreement that we should throw away binaries from builds. I'd encourage something slightly different and then I'd expand on it a bit. Sounds like a plan but perhaps if they are not already? these uploads should be enabled within their own apt sources line. Whilst malicious code can be hidden in source and accompanying packages such as via sidechannel attacks, any additional threats should be avoided or users enabled to avoid them where possible. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/783597.44818...@smtp131.mail.ir2.yahoo.com
Re: Tired of my fellow SysV supporters
previously on this list Russ Allbery contributed: One person in particular is currently creating new throwaway accounts at various free email providers to post violent threats and invective-filled rants to various project mailing lists. Maybe it's Lennart and he's hired a psychologist ;-) -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/845980.95022...@smtp104.mail.ir2.yahoo.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
previously on this list John Paul Adrian Glaubitz contributed: You know that you did this before and you apologized to me in private. If you like, I can post this mail to the public list. You said the exact same things before and I have heard other Debian Developers who think the same way about you. I think you need some balance here as much can be flung in your direction here too. Your problem is that you can't accept defeat. Again, Defeat? That says it all If they have decided on systemd as default then I'd like to see the published reasoning, though I am sure it would annoy me greatly. The fragmentation of Linux (which includes cortex and blackfin kernel support) has begun through an idea that was said to unite and not divide and the benefits are negligible when you consider what linux can already optionally do. OpenRC is also more intuitive and easier to CLI and on install scripts. Promises of uniting leading to the opposite continues to repeat itself through human history, it seems. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/310589.38154...@smtp134.mail.ir2.yahoo.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Wed, 12 Feb 2014 11:25:14 -0500 Paul Tagliamonte wrote: If they have decided on systemd as default [...] https://lists.debian.org/debian-devel-announce/2014/02/msg5.html Can we please end this thread? Sure but perhaps you could save me the trouble to say if there is a general outline of the factors that the decision made was based upon perhaops somewhere in the ctte mailing list archive. Or a round up published before voting. Don't tell me it was just a vote with licensing issues being taken by many over real issues as some sites seem to be saying. Do voters give their primary reasons? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/384598.17177...@smtp111.mail.ir2.yahoo.com
Re: Call to fork
previously on this list Matthias Urlichs contributed: For instance, a daemon which fails to start under sysvinit will not even prevent the services which depend on it from starting up. How terminally stupid is that? Perhaps you should rethink that whilst considering the complexities. I disagree and could easily argue doing so is stupid. I have also done just that for services not designed to work together within rc.local. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/345050.99715...@smtp150.mail.ir2.yahoo.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
previously on this list Svante Signell contributed: What I don't get is why are those people trying to push Debian's decision when they are primarily using a different platform. But I guess it's pure politics and trying to push their own projects. I'm pretty sure there are _many_ Debian users and developers among the people not being happy with the way things are heading :-( Make your voices heard! heading? I have faith and if not I shall just switch distro with a little more work or less convenience for offline machines but miss the guarantee of stability and have some worries and dashed hopes for the future of debian embedded. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/357212.23464...@smtp119.mail.ir2.yahoo.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
previously on this list John Paul Adrian Glaubitz contributed: On 02/11/2014 05:20 AM, Thomas Goirand wrote: It's like being able to customize internal parts of your cars engine when ordering one from your dealer. Customers don't care who the manufacturer of your ignition system is as long it's the best possible one. (Yes, I know comparisons with cars are bad ;)). That's partly not truth. Some customers care, and do customization of their car. No, it's absolutely not. You can have the choice for the interior design, the paint job, the radio, the type of engine and comfort features, but you certainly cannot have the choice on internal parts like the ignition system or starter motor. I'm under the impression Americans customise almost routinely. I know one of my Dad's favourite features of the original mini (mini's may be simple but they won many rallies and are still going) was that almost anyone could take it apart completely in his garage and put it all back together optionally replacing parts. Only the interfaces have to match. That was until he rolled it into a ditch and is still unable to work out how he physically managed to scramble out of the tiny triangular window. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/619879.21733...@smtp145.mail.ir2.yahoo.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
previously on this list John Paul Adrian Glaubitz contributed: systemd is used as the default init system in: - Fedora - Arch Linux - Mageia - openSUSE - SLES (upcoming) - RHEL7 - Frugalware - (see Wikipedia) Plus companies like Intel and BMW are using it in their embedded platforms. So some distros with relatively few users out of the huge number that exist. and two companies shipping products that actually are embedded in a dash and I'm guessing not actually embedded devices or at the very highest end. You don't call a high powered quad arm seven server embedded, do you? Which is a bit like an SME having a minimum of 200 employees when 85% of companies have four. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/876122.10768...@smtp101.mail.ir2.yahoo.com
Re: [Bulk] Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, 11 Feb 2014 20:39:10 +0100 John Paul Adrian Glaubitz wrote: While they loose the warranty which is my main point. Who needs a warranty when it's so straight forward. These days you have an engine with a management system which you have to fix or convince the mechanic that the management system is reporting the wrong thing before he sends it to Mercedes to be fixed at 10 times the price. Or it switches your car off when you don't want it to or dials Mercedes to come pick your car up when you have tried to hide it, like happened to Jeremy Clarkson. Yes, you can replace your init system with anything you like, but don't expect everyone else in Debian to actively support you. In true systemd supporting style. Cheers, mate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/684127.74971...@smtp102.mail.ir2.yahoo.com
Re: [Bulk] Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On Tue, 11 Feb 2014 20:37:59 +0100 John Paul Adrian Glaubitz wrote: Arch, openSUSE and Fedora are among the most popular and widely used Linux distributions where most of the upstream development happens. Show me the numbers, I completely disagree and developers from those ditributions such as RedHat have been equally vocal against systemd. and two companies shipping products that actually are embedded in a dash Those two are multi-billion dollar companies. With many projects where systemd couldn't even hope to be used. The point is you are trying to make a point out of nothing. On the other hand, what companies and distributions and companies actively support Upstart and OpenRC. Meaningless. How many companies support development of /sbin/init? Don't diminish the achievements by the systemd developers when the competition isn't even remotely on par when it comes to momentum and community and company support. I don't wish to get dragged into what has been discussed far better many times before yet again. I have faith that those that have spoken against systemd have shown good reasoning and understanding and the opposite camp largely misunderstands what already exists and the depth of usage with a few minor plus points. I also realise security benefits are often muted and risks misunderstood. Init scripts are here to stay no matter what happens for many reasons, the only question is what is the best default or init just for Debian. Which is easiest to switch to. Which default may cause bugs and/or lend itself to upstreams making worse and less pliable software. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/374770.71754...@smtp103.mail.ir2.yahoo.com
Re: conflict between system user and normal user
previously on this list Peter Palfrader contributed: I would really like to standardize on some prefix. I like _ as a prefix because adduser doesn't allow the local sysadmin to create accounts with that prefix without special flags, which I think makes it a more useful reserved namespace. Just a me too: If we could actually agree and document in policy that the _ prefix is the way to go that'd be great. I'd be more than happy to rename debian-tor to _tor for instance. Guidance (or even code) on how to properly rename existing system users would be appreciated. OpenBSD uses _ntp for ntpd and apparently all services since just after sshd was added to base, so there is some synergy there. Apparently it happened to ensure no namespace collision of system bundled services. On OpenBSD I use the same syntax when adding things like my automounter user for my hotplugd script. So I'd agree with the underscore but see the not allowing the local sysadmin to create accounts easily with it as a bad thing as they could perfectly well want to avoid collisions with packages as much as a debian dev. It is the admins system primarily after all and purposefully getting in the way is completely wrong in my opinion, warnings even with relentless beeping if you must. This is something I disagree with the stance on udev about for removing LAST_ACTION too. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/648834.53502...@smtp102.mail.ir2.yahoo.com
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
previously on this list Sergey B Kirpichev contributed: Doesn't matter) rc.local shouldn't be used by local admin to start services from. Why not use usual init-script? I wouldn't be surprised if rc.local has been around longer than Debian and is meant to run at the end. Particularly for a service that isn't packaged it may be useful and expected to run last. It seems perfectly logical for a user to expect a local service or command to run last ie as if a user did so after boot up. The special hurd case should run after rc.local as a special case perhaps an include ./rc.local.oddball. The arguments online of services should be shutdown gracefully in case they have problems on the next bootup by upstart and systemd seems to be nonsense. On OpenBSD you have rc.shutdown but in any case if the system dies or crashes, plug pulled etc., then services should start just fine on reboot or be re-written rather than being flaky rubbish In fact in that case abusing rc.local means a higher likelihood of testing for and removing flaky services or fixing bugs before that annoying time of things breaking which almost always happens at the worst time possible. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/863947.50998...@smtp124.mail.ir2.yahoo.com
Re: conflict between system user and normal user
previously on this list Simon McVittie contributed: So I'd agree with the underscore but see the not allowing the local sysadmin to create accounts easily with it as a bad thing as they could perfectly well want to avoid collisions with packages as much as a debian dev. A concrete example, please? If you (as local sysadmin) always create accounts matching [a-z]*, and Debian packages always create accounts matching _*, then your local actions can't collide with Debian packages. Oops, I guess I read it too fast, sorry for wasting your time. I thought system accounts were going to get the underscore. Which means the preventing admin makes more sense but the synergy possibly being the opposite. In any case, before this morning I thought OpenBSD underscored users were chrooted or something along those lines and it turns out it was the Absolute OpenBSD book that says they are unpriviledged users which from taking a look stands up with mysql package/port unpriviledged user also using underscore. The fact that basically all of the daemons are unpriviledged is a testament to OpenBSD I guess. So the mailing list thread I based OpenBSD using underscore for non base users was wrong despite being made by a usually reliable source or actually I'm guessing has possibly changed now that basically all base daemons are unpriviledged. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84316.34880...@smtp108.mail.ir2.yahoo.com
Re: Valve games for Debian Developers
previously on this list Russ Allbery contributed: Just want to mention, I'd really appreciate it if jockey and so polkit could become an optional dependency of the steam launcher (Ubuntu) and so I guess steam OS as the Nvidia functionality is not used or needed when I use steam. Despite Nvidia having faster opengl atleast with Wine I've just switched to AMD as they are far less closed than Nvidia and so KMS works on OpenBSD. Polkit is riskier not to mention less manageable than sudo and I have no need for it and shouldn't be forced to install it and even though I buy steam credits from secure machines and don't store my card details with steam and you may say it is only gaming, Gaming with incoming traffic is still a risky use of a computer. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/648867.92600...@smtp138.mail.ir2.yahoo.com
Re: Bug#735927: general: X *always* crashes when ram is full
previously on this list Roger Leigh contributed: With an SSD, you really don't want /tmp or swap on it; Why?, due to limited write cycles? As long as it is a modern SSD (years) or one of the old ones one with a sandforce controller (OpenBSD dev let me know about that) then it has a good 20% extra space above it's listed gigabytes reserved unusable for wear levelling meaning this is a non issue even when full? Unless he's worried about not being able to wipe the swap? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/801542.40858...@smtp127.mail.ir2.yahoo.com
Re: Bug#735927: general: X *always* crashes when ram is full
On Mon, 20 Jan 2014 14:30:24 + Roger Leigh wrote: This is a system with 8 cores @4GHz, 16GiB RAM, over 16GiB swap, so should be pretty performant, yet /tmp on an SSD made it crawl and freeze continually. Interesting, have a look if it states the write access time spec in the datasheet (if available) of that SSD? Though when I've looked for write access time on off the shelf SSD drives it usually only mentions throughput or reading. Do you know if it slows the build if you use it for the source code? If your not sure it's a sandforce or has similar wear levelling then obviously don't try it in case you wear it out, though as it's your root I don't suppose you will try it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/829972.77857...@smtp115.mail.ir2.yahoo.com
Re: Bug#735927: general: X *always* crashes when 5 youtube video opened
previously on this list Andrew Shadura contributed: Apparently, you haven't got free disk space left. That's sort of expected that when there's no free disk space programs start crashing randomly. Shouldn't happen if you partition your disks and even then only carelessly written programs like mythtv and KDE crash or refuse to start but them two may have been fixed now in this regard. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/926698.27371...@smtp147.mail.ir2.yahoo.com
Do you use OpenSSH
It certainly wouldn't be as secure or successful and may not even exist without OpenBSD. OpenBSD currently has a shortfall for it's electricity costs and so any donation's would be much appreciated by the project. Sorry if you see this as spam it won't happen again. ___ The OpenBSD project uses a lot of electricity for running the development and build machines. A number of logistical reasons prevents us from moving the machines to another location which might offer space/power for free, so let's not allow the conversation to go that way. We are looking for a Canadian company who will take on our electrical expenses -- on their books, rather than on our books. We would be happiest to find someone who will do this on an annual recurring basis. That way the various OpenBSD efforts can be supported, yet written off as an off-site operations cost by such a company. If we reduce this cost, it will leave more money for other parts of the project. We think that a Canadian company is the best choice for accounting reasons. If a company in some other jurisdiction feels they can also do this successfully, we'd be very happy to hear from them as well. I am not going to disclose the actual numbers here. Please contact me for details if serious. Thanks. ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/972769.25938...@smtp112.mail.ir2.yahoo.com
Re: xpdf removed from testing?
previously on this list Svante Signell contributed: Is it true that xpdf is about to disappear. I like that program very much. I like it too but it's save dialog is pretty terrible. Have you checked out mupdf. No save but similar otherwise. p.s. qpdfview is shaping up and remembers tabs too. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/96511.59881...@smtp101.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Ben Hutchings contributed: In other words, Canonical gets the right to take a free software contribution and make it proprietary. The contributors gets to own the software, and can continue releasing it as free software, but can't prevent Canonical from making non-free versions of it. I don't find that an acceptable situation. But I saw today that this paragraph goes on with: As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date. My understanding (as a non-expert on legalese en_*) is, that Canonical would only be allowed to re-license the Contribution under a dual-license scheme, with (a) the original license, and (b) $whatever-they-want. [...] Yes, but that says nothing about the rest of the program that it's a part of, nor that they will continue to distribute the Contribution. Since the contributor, retaining copyright, can give that license to anyone anyway, this condition doesn't appear to have any meaningful effect. Ben. I don't see why this should affect the decision at all personally especially far less than less co-operative upstreams though perhaps a pure BSD license could be seen as a free-er plus point. It basically means they have reserved the right that they may never use but put in jut in case likely for other projects to stop contributing or publishing the source of their work to the project but continue to use the communities past work. The community could even then decide that just canonical was not allowed to use any of their changes from then on whilst still benefiting from Canonical's past work. At the end of the day whatever increases the chance of code being done for good reasons and the good of the community is what is important and forcing publication may?? help twist the arms of the less important contributors but also hinders that likelihood in reduced initial take up anyway possibly including partial release. Apache's BSD based and Googles BSD based licenses and many others would all allow this, what has been and is going to be contributed in a constructive and forth coming way for the good of all is what is important. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/304170.20633...@smtp139.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Theodore Ts'o contributed: So hopefully that is something the technical committee will take into account --- how well things are documented, both in terms of a comprehensive reference manual, and a tutorial that helps people with common things that system administrators might want to do. The docuementation you pointed to at http://upstart.ubuntu.com/cookbook/ is something I wish I had access to when I first was forced to use Upstart; maybe if Upstart was as polished back then, I might not have given up on Ubuntu in disgust. I would like to have seen that, I think the man page found via apropos upstart should point to that doc in /usr/share as well as the http for offline use at the very least, even if a pdf/html has to be copied off to be read on a server. I don't use Linux for any servers that I currently deploy but I can see that being very annoying in certain situations. I have had my time wasted with almost every init system except OpenRC which is pretty much intuitive but still not so intuitive as OpenBSD's being my favourite where you have around 6 files (few for lockdownability but actually simplicity too) ALL in /etc and with rc in the name and one directory called rc.d all of which have very good man pages including giving reasons for why things are done in as few files as possible even though you could work it out yourself rather quickly. Of course good man pages is one of OpenBSD's watch words or primary goals and security and minimal defaults comes before speed and ease of average user use so it shouldn't be that surprising. rc.conf has the defaults and the line . /etc/rc.conf.local rc.conf.local can have overrides such as sshd_flags=NO for off or sshd_flags= for default or sshd_flags=-4 for ipv4 only -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/947826.52397...@smtp103.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Wouter Verhelst contributed: By absense of documentation, are you referring to the almost 10% of the source base that are comments or the 15% that is DocBook XML based documentation? (Almost 14kLOC and almost 36kLOX, respectively.) That particular comment was not referring to systemd specificaly. I haven't looked at the systemd code in much detail myself. What I wrote in the above-quoted post was based on the comment of this OpenRC developer. Perhaps I should have checked some more before repeating that comment, though. Well he actually said that seperating/finding the logind code and any relevent documentation was difficult. So an accurate rebuttal would be ?kLOC and ?kLOX concerning logind and perhaps a description of all the functionality of logind from those comments. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/290887.44189...@smtp132.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Zbigniew Jędrzejewski-Szmek contributed: Hi Helmut, exec vs. ExecStart= and export vs. Environment= is easy. Anyone can whip up a sed script to convert between those. The question is how to deal with more advanced options. Let's say that I have a systemd unit with CapabilityBoundingSet=CAP_SYS_TIME# limit the capability bounding set to CAP_SYS_TIME PrivateTmp=yes# run with unshared /tmp InaccessibleDirectories=/home # run without access to /home WatchdogSec=60 # consider the service dead if it hasn't pinged the # manager for in the last minute Restart=on-failure# restart service on watchdog failure or unclean exit This isn't a question of syntax, it's a question of significant functionality in the manager. I think that sharing service descriptions between disparate init managers is infeasible, unless we forbid the use of anything but the basic features. Couldn't they just be ignored not to mention already having existing or far more functional and robust *options* that work with any init system. Even SElinux has people wanting to use RSBAC or grsecurities RBAC because they have a better security record due to more secure architectures and rules. and on another matter I personally much prefer a setcap (again or other options like RBAC) shell line to CapabilityBoundingSet=CAP_SYS_TIME Another thing that is turning into a significant gap is socket activation. In systemd, socket activation allows the service to receive multiple open sockets (e.g. ports 80 and 443 for an httpd server). Socket activation of daemons is cool: No it isn't and has been argued over not long ago, so as I have been requested to and am now trying (even harder) it would be good if we could keep the S/N ratio down. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527896.83523...@smtp118.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Helmut Grohne contributed: Most participants in this thread appear to agree that the sysvinit *interface* for services (shell scripts) is suboptimal. Not so sure, I have various thoughts on this and even the reasons that it is considered sub optimal but think some like me have chosen not to bring this up out of fear of opening another can of worms which has already been discussed many times. I have always found OpenRC quite nice in being intuitive, quick and flexible to administer though compared to debian's sysv implementation, upstart and systemd. The freedom arguments can be combatted somewhat with the 'modern' init having options to use shell scripts but then the question becomes whether services start needing hacking and recompiling for things like embedded usage or any other unexpected scenario or desire and I guess Gentoo is heavily into embedded and unexpected scenarios like debian. On the other hand if those disrespectful services choose to ignore unix philosophy then it may simply be an extension of dependency hell in any case and so is of little matter except discouragement. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/922863.83523...@smtp118.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Jonathan Dowland contributed: Couldn't they just be ignored not to mention already having existing or far more functional and robust *options* that work with any init system. A cursory glance at the example above… PrivateTmp=yes InaccessibleDirectories=/home …would suggest that simply ignoring such things could be a major security concern. So, no. Well I meant that they would be used by systemd and ignored likely noisily by default by others. However this really should be the job of the service in any case as depending on a third party service for security that isn't extra such as potentially PrivateTmp that apache/php may need (likely in a /var chroot in this case though) is asking for trouble. and on another matter I personally much prefer a setcap (again or other options like RBAC) shell line to CapabilityBoundingSet=CAP_SYS_TIME Presumably your preference is not purely down to syntax. What is it down to? For something that is as long and no more descriptive than the shell it replaces it is simply adding obfuscation that fails to teach anything useful to users for use in other contexts and doesn't have a man page which like so often on Linux needs improving for setcap but that is of no importance to the better practice of empowering users who may become the next generation of devs. No it isn't and has been argued over not long ago, so as I have been requested to and am now trying (even harder) it would be good if we could keep the S/N ratio down. I'm afraid you're failing with sentences such as the above. True and certainly could have been worded more tactfully. I was referring to the thread from the 27th Aug entitled Custom Reload command/signal in upstart -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/818151.66282...@smtp124.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Russ Allbery contributed: Well I meant that they would be used by systemd and ignored likely noisily by default by others. However this really should be the job of the service in any case as depending on a third party service for security that isn't extra such as potentially PrivateTmp that apache/php may need (likely in a /var chroot in this case though) is asking for trouble. No, it should *not* be the job of each service to reimplement tricky security measures. They should be implemented in one place or a small number of competing places that are thoroughly tested and that have been examined with lots of eyeballs, and then reused by everyone else rather than having them attempt to roll their own strategies. This applies to several features in upstart and systemd. Socket activation is another excellent example. Anyone care to guess how much badly-written code to handle listening to a network socket currently exists in the archive? How much of it causes the daemon to fork and exit in the parent before it's actually listening to the network, thus breaking boot ordering? And that's despite the existence of the inet superserver, which hopefully a lot of packages are using rather than rolling their own. It's one thing to avoid a monoculture. It's quite another to chase avoidance of a monoculture into a nasty case of Not Invented Here. Services should not be responsible for doing things that can be done properly by well-tested and robust system services for exactly the same reason that services should not use their own implementation of AES and should instead rely on one of the several robust and well-tested crypto libraries. Well I completely disagree, yes they should use or atleast reference good well audited shared references but code for security should be tailored to the almost always simpler job at hand otherwise you will always be less secure and doing so actually increases eyeballs on the code. Bringing it back to PrivateTmp what you are certainly doing is adding complexity about whether systemd is running and has done this or not and for what good reason, which then raises questions and less audited code for all the other use cases. If you analyse the really secure packages on the two sides guess which has the extremely low vulnerability track record. You may also stop the dev from providing extra layers of security because the generalised behaviour is out of their domain and they don't need to think about it. If on the other hand you are talking about making it easier for some programmers who are not willing to take the time to be careful then you may have a point for backing things like polkit but I would say they should stick to unpriviledged user operations then as this generalisation and misunderstanding/unfamiliarity does and will lead to more exploits and they shouldn't be doing anything risky as root if they are not willing to be careful anyway. And no it isn't exactly the same reason as well defined libraries with very specific low level jobs at all, often even standard c libraries functions are the right tool but sometimes you take part of it and make something more correct. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/68396.31640...@smtp104.mail.ir2.yahoo.com
Re: let's split the systemd binary package
previously on this list Philipp Kern contributed: I'm not sure why our enterprise users don't count as users as well. Of course they do even if the couple of people possibly concerned with it that I know use.. is it Citrix? I was merely pointing out that it is an extremely small minority of Debian users but possibly? a majority or major section of RedHats paying customers and even more so it's revenue stream (pay more). This should be considered in weighting the pros and cons that's all especially when terms like real features (largely gone undefined) are being banded around. As I have said issues that affect many and people may actually notice have gone are easily fixed as far as I am aware (certainly the ones mentioned like suspend, as I do so when disabling polkit very easily without compilation). So how many debian Gnome users will notice the breakage aside from suspend and ? how many will continue to use Gnome if the default is changed as has already been raised. On top of that, large organisation's should have no problem solving this and do they use debian or want support from Red Hat/Citrix in most cases? I don't need the dbus system bus personally either but I understand the vast vast majority do in current setups, so that is a real issue of the future if permitted to land into the kernel as the only option (I doubt it) and as Canonical/Ubuntu and Google have concerns on multiple fronts here I think it is certainly worth waiting that out and should not really be used as an argument currently. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/905842.70346...@smtp101.mail.ir2.yahoo.com
Re: let's split the systemd binary package
previously on this list Olav Vitters contributed: On Tue, Oct 29, 2013 at 06:37:35PM +, Kevin Chadwick wrote: Of course they do even if the couple of people possibly concerned with it that I know use.. is it Citrix? I was merely pointing out that it is an extremely small minority of Debian users but possibly? a majority Do you have any references to back up how you know this? Or just merely guessing? It seems like pure guesswork. Until someone points out some new functionality I have missed, this is surely obvious especially if the *buntus are included. This should be considered in weighting the pros and cons that's all especially when terms like real features (largely gone undefined) are being banded around. As I have said issues that affect many and people may actually notice have gone are easily fixed as far as I am aware (certainly the ones mentioned like suspend, as I do so when disabling polkit very easily without compilation). So how many debian Gnome users will notice the breakage aside from suspend and ? how many will continue to use Gnome if the default is changed as has already been raised. Are you taking up ConsoleKit development or not? Loads of things could theoretically maybe be done. What matters is something concrete. I have no use for consolekit and it doesn't run on my systems and none of my users notice, so why would I?. What I don't agree with is this ultimatum that something must be done and making a mountain out of a trench. Worst case is holding systemd back or using consolekit and all this may be solved in x number of unknown ways by the time it matters to stable. I'm also sure those that need session tracking could easily afford to sponsor the work if they need it and use Debian. On top of that, large organisation's should have no problem solving this and do they use debian or want support from Red Hat/Citrix in most cases? Please don't turn this into a Canonical vs Red Hat thread. I am not, I have spotted and cited trends and made statements perhaps without citing other annoying trends in detail that may alter my tone to only parts of RedHat (such as documentation, configuration methods...). I respect the company as a whole and don't forget many Redhat employees have publicly spoken out against systemd. I was merely responding to the post of lennart's that may make many think there is no alternative, when they specifically have been talked about recently. There are always alternatives. Who knows even linux itself may fork one day but I hope not. I don't need the dbus system bus personally either but I understand the vast vast majority do in current setups, so that is a real issue of the future if permitted to land into the kernel as the only option (I doubt it) and as Canonical/Ubuntu and Google have concerns on multiple fronts here I think it is certainly worth waiting that out and should not really be used as an argument currently. GNOME relies on d-bus for various things. Not liking d-bus doesn't change that fact. Who said I didn't like dbus. I even said the session bus should be used where it is best suited. I do think it is often used when it shouldn't be and do disagree with parts of dbus. dbus has atleast 3 major distinct functions that I can think of. Running programs as root is one I completely disagree with and with evidential good reason. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/908332.97162...@smtp144.mail.ir2.yahoo.com
Re: Proposal: switch default desktop to xfce
you need something with big buttons that is finger-friendly, I'm surprised how much accuracy a capacitive multitouch mobile has when in touchscreen terms it is actually extremely poor (3-4mm) exacerbated by them not responding to nails (conductive), a trade-off for size and multitouch. Many have much better accuracy (infra-red, resistive) and certainly will have multitouch too in the future. Websites having big buttons represented by tiny ones visually on Android is certainly true due to this. My conclusion is that the right UI to choose is quite machine-specific and also user-specific. The 10 touch Baanto has very good accuracy ( mm) and is an example of an external infra-red that actually doesn't work with Linux due to an indirectly related bug last time I checked even though it is alleged to by Baanto. Some accurate single touch resistive touches also work as a standard mouse though they require detection and the movement being inverted, but it would be a very simple driver. The supplier had died but it seems to have been revived recently. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/106418.70388...@smtp117.mail.ir2.yahoo.com
Re: Proposal: switch default desktop to xfce
OK. I suggest that we *try* that for now. If we try, what will be the criteria for assessing whether the experiment has been successful (and hence worth keeping for Jessie) or a failure (and hence reverting it)? I think it should be considered that there has been much improvement upto 4.10 and 4.11 even has some useful multi desktop improvements (above and below) so it would be better if 4.10 or higher was the assessed version. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/390320.67774...@smtp127.mail.ir2.yahoo.com
Re: let's split the systemd binary package
E.g. XFCE either wants ConsoleKit, or logind. If you look at ConsoleKit, you'll notice it is NOT maintained. XFCE *needs* neither and in fact the vast vast majority of users do not either. I check the spec files for Fedora, Mageia, openSUSE. They all seem to require logind. For Arch, seems as well, but not sure (difficult to verify). For Debian it is a recommends. So all the systemd using Distro's! How about Gentoo, Slackware, LFS and many many others? Needs neither seems to be true based on the recommends, but vast majority seems incorrect. I do wonder what breaks though :P By vast majority I was meaning user requirements and not distro packagers expectations, user requirements is actually the metric which should count the most and most users do not need session tracking, it can actually get in the way (one user using many logins, shutdown, usb access etc.). User requirements are normally automatically reflected by unix developers but RedHats enterprise requirements and extensive dev time have the potential to swing that even if they rectify it from time to time. p.s. Whoever decided to use non unique names in gdm over unique usernames for user selection must have had a strange thought process going on. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/583301.3469...@smtp126.mail.ir2.yahoo.com
