Nvidia No GLX to using OpenGL...
Hello, I installed Nvidia drivers from https://wiki.debian.org/NvidiaGraphicsDrivers#Version_195.36.31 - Everyhting works but when open the OpenGL/GLX Information option on the nvidia-settings panel it sends: "Fail to query the GLX server vendor." and glxgears sends: "Xlib: extension "GLX" missing on display ":0.0". Error: couldn't get an RGB, Double-buffered visual" My xorg.conf: "# nvidia-settings: X configuration file generated by nvidia-settings # nvidia-settings: version 1.0 (buildd@biber) Tue May 18 10:36:08 UTC 2010 Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 0 0 InputDevice"Keyboard0" "CoreKeyboard" InputDevice"Mouse0" "CorePointer" Option "Xinerama" "0" EndSection Section "Files" EndSection Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" # HorizSync source: xconfig, VertRefresh source: xconfig Identifier "Monitor0" VendorName "Unknown" ModelName "CRT-0" HorizSync 30.0 - 82.0 VertRefresh 50.0 - 75.0 Option "DPMS" EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "GeForce 8600 GT" BusID "PCI:5:0:0" EndSection Section "Screen" # Removed Option "TwinViewXineramaInfoOrder" "CRT-0" # Removed Option "metamodes" "CRT-0: 1920x1080 +1440+0, CRT-1: nvidia-auto-select +0+0" Identifier "Screen0" Device "Device0" Monitor"Monitor0" DefaultDepth24 Option "TwinView" "1" Option "TwinViewXineramaInfoOrder" "CRT-1" Option "metamodes" "CRT-0: NULL, CRT-1: nvidia-auto-select +0+0" SubSection "Display" Depth 24 EndSubSection EndSection " Please Help! Thanks
Re: Nvidia No GLX to using OpenGL...
Op Sat, 11 Oct 2014 10:13:55 +0200 schreef Gábor Hársfalvi : Hello, I installed Nvidia drivers from https://wiki.debian.org/NvidiaGraphicsDrivers#Version_195.36.31 - Everyhting works but when >open the OpenGL/GLX Information option on the nvidia-settings panel it sends: "Fail to query the GLX server vendor." and glxgears sends: "Xlib: extension "GLX" missing on display ":0.0". Error: couldn't get an RGB, Double-buffered visual" My xorg.conf: To make sure all the necessary packages are installed run: $ sudo apt-get install nvidia-glx and to verify that all the packages have the same version number run: $ apt-show-versions | grep nvidia Don't forget to reboot after installing a Nvidia package Success, floris
Re: Prolem with external monitor
On Vi, 10 oct 14, 11:24:55, Bret Busby wrote: > > Can Debian 7 run an external monitor? Definitely, I'm using my TV as external monitor sometimes. Could you please attach your Xorg.0.log? Inlining works as well if you take care not to break long lines. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: question about systemd
Ahoj, Dňa Fri, 10 Oct 2014 23:31:02 +0100 Brian napísal: > On Fri 10 Oct 2014 at 21:00:41 +0200, Slavko wrote: > > [snip] > > > LANG=C aptpu libsystemd-login0 libsystemd-daemon0 > > The following packages will be REMOVED: > > [Snip] > > > cups-daemon : Depends: libsystemd-daemon0 (>= 31) but it is not > > going to be installed. > > If you are going to provide information for a testing or unstable > installation the least you can do is ensure it is up-to-date. It is a > necessary condition for a fruitful discussion. Dont't be quick. It take a lot of work to get the my system working again (with snapshots.debian.org help), after i test latest testing versions. After new version will works for me, i will have it updated, until i will have cca 50 in hold state and some custom recompiled to remove the systemd dependency: regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: question about systemd
On Vi, 10 oct 14, 20:57:09, Peter Zoeller wrote: > I tell you what why don't you install Fedora the originator of this and try > to remove systemd and install sysvinit or Upstart and then we will talk. > Left Fedora for this very reason, lack of choice. As far as I understand Fedora has different goals, so it's quite natural for them to make design choices for those goals. Debian on the other hand has a quite general goal of providing a high quality free operating system. In practice this means that Debian will allow many programs providing similar functions to co-exist in the archive as long as they play nice with each other as much as possible[1]. However, as a side effect of this the complexity of Debian increases[2]. Having upstream developers and package maintainers support more than one init system means more work for them. So the only way to ensure Debian is able to support more init systems is to get involved. There are many things you can do: - If you use applications that depend on libpam-systemd help with systemd-shim / cgmanager in any way you can - If you want your services to still run fine under different inits help maintain the support for that init[3] - provide support for other users / write documentation on how to run Debian with other init systems - etc. It's simply pointless and demotivating to ask "Debian" to do something for you. The Debian Project is not even a legal entity and its Developers are free to *not* work on something if they choose so. If there's nobody willing to do the work IT WILL NOT BE DONE! [1] there are many examples here, like desktop environments, window managers, MTAs, webservers, etc. [2] yep, the complexity argument cuts both ways [3] e.g. for sysvinit you could help the package maintainer transition to init-d-script(5), which will make it much easier to maintain sysvinit support in the long term Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Proposal: An alternative to mailing lists which isn't a forum
On Jo, 09 oct 14, 23:16:33, softwatt wrote: > > Instead of a mailing list, let there be an IMAP/POP account, let us call > it i...@debian.org. However, it isn't a normal IMAP account: > > - It is public, and not a traditional private imap account. > - It accepts all logins, regardless of the password typed. > - It is read-only, users cannot directly modify it. > - Users can only use it to read, they cannot send >mails as i...@debian.org > - It serves as the "forum". > - The topics and sub-topics are simply folders and sub-folders. > - In order to read the "forum", one simply adds the imap >account to one's mail client. > - In order to post something new, one simply replies to the >relevant post (The FROM is one's own mail, and not >i...@debian.org) If you want to go forward with this I would suggest you just do it. If some Debian Developer finds your idea interesting you could even get a domain like imap.debian.net. You could set up several servers/accounts: lists@imap.d.n @alioth.imap.d.n @bugs.imap.d.n (for people that want to follow individual bugs only, since there are also the debian-bugs-* lists) I think you *might* encounter issues with scalability: i.e. IMAP servers are built to handle many clients accessing different mailboxes, not sure how they will handle many clients accessing the *same* mailbox (but then the developers might be interested in fixing the issues ;). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: question about systemd
On 10/10/14 18:15, PETER ZOELLER wrote: And this is being hard coded in my opinion since it forces it to be installed as a default with no other option given and required for example if you want to use Gnome. It turns out to be the case that cases where Gnome fails to operate correctly without systemd as PID 1 are in fact being treated as bugs: https://bugs.debian.org/release-critical/other/testing.html - the list of release-critical bugs in Debian jessie, which refers to: https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=759745 - a release-critical bug filed against gdm3, the X display manager provided as a component of Gnome 3. Failure of the Debian Installer to offer a convenient mechanism for selecting the init system to be installed can reasonably be argued to be a bug in the installer, which you might want to consider reporting. This system has been shown to be troublesome, is only one of many ways to handle the boot process, and forcing other distributions to either accept it or fall by the way side. A rather strong arm tactic of Microsoft. I loved Linux because of the freedom to choose, modify and configure it to what I want and need. Right now there are only two distro's left that do not use systemd and soon there will be none. This is madness. Systemd is a kludge, poorly designed, overly complex. and too convoluted leaving it open to being cracked and its host system compromised by the crackers of the world. It seems to me that if a cracker is in a position to exploit whatever attack surface systemd presents, your system has already been compromised. Until ALL the bugs are out and it has proven itself to be 100% stable and 100% secure it has no business being a part of a stable operating system. If that's your position, why are you using an operating system based on the Linux kernel? The Linux kernel has bugs, it is not 100% stable, and it is not 100% secure. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543903e2.9020...@zen.co.uk
Re: How to do this ?
On Vi, 10 oct 14, 19:51:50, Erwan David wrote: > I want to have a system which boots, and starts a subset of daemons. > > Then afterward I ssh to it, do something which 1) mount an encrypted > disk, 2) start other daemons (which depends on the encrypted disk). > > I know how to do this with policy-rc.d, how can I do this with systemd ? My first though on doing this with sysv-rc would have been runlevels, why do you even need policy-rc.d? My first though would be targets, but it would be better if you would show us your policy-rc.d, because you might have dismissed runlevels for reasons you are not telling us. > I know this list may not be the best place to ask, feel free to point me > to another way to get help. This is definitely the correct list for such a question. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Installer does not detect ethernet card
On Sb, 11 oct 14, 00:28:24, helpseekingtour...@gmx.net wrote: >Hi >Tried to re-install Debian 7.6 wheezy from USB-Stick on a Lenovo >ThinkPad T420. At the step 'Detect network hardware' pops up the >message 'No Ethernet card was detected. If you know the name of the >driver needed by your Ethernet card, you can select it from the list'. >This does not work either. >The notebook has an Intel 82577LM Gigabit (Hanksville) Digital Office >ethernet adapter. The selection of the 'e1000'-driver shows up the >Detect network hardware installer page again. Cable to active, working >DHCP router is inserted. Country selections work fine and beforehand, >the installer seems able to mount the existing harddisks. It seems the installer's kernel doesn't recognize your Ethernet card. >Since Debian already is installed I am confused by that message, what >do I miss? What version (more precisely, which kernel)? You could try either a newer installer (i.e. Jessie, you can still install stable in expert mode) or a stable installer with a backported kernel if those still exist (search the web for 'kmuto image'). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: question about systemd
On Sb, 11 oct 14, 11:18:10, Martin Read wrote: > > Failure of the Debian Installer to offer a convenient mechanism for > selecting the init system to be installed can reasonably be argued to be a > bug in the installer, which you might want to consider reporting. But most likely severity 'wishlist' since this was not possible before either. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: question about systemd
On Vi, 10 oct 14, 06:57:18, PETER ZOELLER wrote: > This is really ticking me off. We are becoming just like Microsoft > that one size fits all. Linux has always been about choice and > modularity and reconfigurability where a user or admin can choose that > what suits him/her and the type of system they want. You want > sysvinit you use Debian or Slackware, want Upstart go to Ubuntu, want > systemd go to Fedora/Redhat. Where in all this is my choice to have > my system boot via the means I or any user or admin considers to be > the appropriate method to boot their system? What's wrong with you > people? Have you lost sight of why Linus designed this system? Its > about simplicity, modularity and reconfigurability. You might want to check your facts: Linus Torvalds "only" created the Linux kernel, which is notoriously monolithic[1]. [1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Using PuTTY with Debian GNU/Linux Systems
In response to encouragement from several people on this list, I have published a new web page titled "Using PuTTY with Debian GNU/Linux Systems". It is available here: http://users.wowway.com/~zlinuxman/putty.htm All feedback, both positive and negative, is welcome. In particular, if there are any factual errors on this page, I especially want to know about that. A number of people have encouraged me to create a Debian wiki article on this subject, and I'm not ruling that out, but at this point I hesitate to do so primarily for two reasons: (1) It is specifically the Windows version of PuTTY that is being discussed, not the Linux version, even though PuTTY is being used to access a Debian GNU/Linux system; and (2) The above web page recommends making modifications to Debian source packages. The idea of a wiki article is to document how to use Debian, not how to fix Debian. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/625567714.3984473.1413027246857.javamail.zim...@wowway.com
Re: question about systemd
On 10/10/2014 at 07:53 PM, James Ensor wrote: > On Fri, Oct 10, 2014 at 7:31 PM, John Hasler > wrote: > >> James Ensor writes: >> >>> My impression is that the idea of "systemd's entanglement" has >>> been blown way out of proportion. >> >> The entanglement discussed here earlier had to do with the design >> of the Systemd suite, not with dependencies. (Well, there was some discussion about the dependencies side of thing as well, but I think that's more an effect of the design of the systemd suite rather than a primary issue of its own.) > Exactly, and that has been blown way out of proportion. You do not > need to have systemd installed or running to have a usable > Debian-testing install. Er... how do these two sentences make sense together? If I'm reading you correctly, you're claiming that the entanglement involved in the design of the systemd suite has been blown way out of proportion, and in support of that you're citing the fact that you do not need to have systemd installed to have a usable Debian testing system. But whether or not you have to have systemd installed to have a usable Debian testing system is not about the design of the systemd suite; it's about dependencies. So your citation seems to have nothing to do with the claim at hand. Is there something I'm missing that makes this make sense? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Proposal: An alternative to mailing lists which isn't a forum
On 10/11/2014 01:20 PM, Andrei POPESCU wrote: > If you want to go forward with this I would suggest you just do it. If > some Debian Developer finds your idea interesting you could even get a > domain like imap.debian.net. Yes, I think that's the way to go. People are far more likely to adopt a ready-to-deploy solution than a theoretical proposal. But I'm interesting in hearing more opinions first. > You could set up several servers/accounts That is not needed. Different lists can simply be different folders of the same account. IMAP supports ignoring / subscribing to specific folders. >IMAP servers are built to handle many clients accessing different mailboxes, not sure how they will handle many clients accessing the *same* mailbox That's a very good point. signature.asc Description: OpenPGP digital signature
Re: question about systemd
Hi. On Sat, 11 Oct 2014 13:53:20 +0300 Andrei POPESCU wrote: > On Vi, 10 oct 14, 06:57:18, PETER ZOELLER wrote: > > This is really ticking me off. We are becoming just like Microsoft > > that one size fits all. Linux has always been about choice and > > modularity and reconfigurability where a user or admin can choose that > > what suits him/her and the type of system they want. You want > > sysvinit you use Debian or Slackware, want Upstart go to Ubuntu, want > > systemd go to Fedora/Redhat. Where in all this is my choice to have > > my system boot via the means I or any user or admin considers to be > > the appropriate method to boot their system? What's wrong with you > > people? Have you lost sight of why Linus designed this system? Its > > about simplicity, modularity and reconfigurability. > > You might want to check your facts: > > Linus Torvalds "only" created the Linux kernel, which is notoriously > monolithic[1]. > > [1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate Yet, being monolithic, it provides hugezillion compile options and lots of kernel modules which can be loaded and unloaded at user's pleasure. Therefore Linux kernel is about a choice :) Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011155602.26a8ecc9c5c931c9986cb...@gmail.com
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: > > Some complexities you can encapsulate or hide, or expose in an > organized manner so that that are easier to deal with. Others, no. [big snip] The complexity argument can be used both ways: - the Unix way (do one thing and do it well) leads to many small tools that can be combined in different ways, where each tool has its own quirks, bugs, release schedules, etc. that only increase complexity - sysvinit (/bin/init) is indeed quite simple, but in practice it's own mechanisms (/etc/inittab) are only used to start sysv-rc (/etc/init.d/rc), which starts all other initscripts, poorly written (/etc/init.d/skeleton itself is known to have bugs) in a (poor) programming language (shell script) with many different implementations (bash, dash, etc.). The scrips are not even enough, they have to rely on additional tools like start-stop-daemon(8) with their own quirks and bugs. - each service/daemon is implemented in its own unique way, with different methods of running (quite often multiple ways, depending on start-up switches, like foreground, forking, etc.), reloading, logging, etc. - computers have gotten quite complex themselves with removable devices, complex network connectivity, etc. - multiple users on the same system (GNU/Linux is supposed to be a multiuser system, isn't it) with different backgrounds, level of technical understanding, expectations, etc. It feels to me like systemd (the project) is rather *trying* to reduce complexity, by providing: - a clear and simple way (unit files) to declare what a service needs and how it should be run and a clear and simple method for the daemon to notify when it is ready to provide its service if its authors choose to implement it - mechanisms to deal with badly behaved daemons as well as provide proper isolation (e.g. cgroups, tmp files handling, etc.) - mechanisms to deal with the complex interactions between daemons, devices, networks, etc. - a logging mechanism that can capture *all* output of a daemon (stdout, stderr, logging) - a unified way to manage users (as in humans) and their complex ways of interacting with the computer (different privileges, local, remote, etc.) - etc. Is systemd (the project) trying to do too much? Possibly. Would it be better if this was done in a modular design *done right*? Probably. Yet, none of the solutions so far has *really* caught on. daemontools, runit, s6, init-ng, etc. and even upstart were either never adopted on a large scale or eventually abandoned in favor of systemd. As far as I understand Linus Torvalds himself admits that a modular kernel design is better, yet he choose to make Linux monolithic. On the other hand Hurd is still not even in a releasable state. Could it be that a modular design for such complex tasks becomes too difficult to *do it right*? Is systemd going to change the GNU/Linux ecosystem? Definitely. Will this change be good or bad? Only time will tell, but I'm quite sure that even if the change will turn out to be bad it will *not* destroy GNU/Linux, but help it evolve in better ways. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: question about systemd
On Sb, 11 oct 14, 15:56:02, Reco wrote: > On Sat, 11 Oct 2014 13:53:20 +0300 > Andrei POPESCU wrote: > > > > Linus Torvalds "only" created the Linux kernel, which is notoriously > > monolithic[1]. > > > > [1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate > > Yet, being monolithic, it provides hugezillion compile options and lots > of kernel modules which can be loaded and unloaded at user's pleasure. > Therefore Linux kernel is about a choice :) $ ls /lib/systemd/systemd* | wc -l 38 (no, I won't be bothered to look up all systemd compile options) I think we're running is circles, so I'll stop. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Proposal: An alternative to mailing lists which isn't a forum
On Sb, 11 oct 14, 15:07:31, softwatt wrote: > On 10/11/2014 01:20 PM, Andrei POPESCU wrote: > > If you want to go forward with this I would suggest you just do it. If > > some Debian Developer finds your idea interesting you could even get a > > domain like imap.debian.net. > > Yes, I think that's the way to go. People are far more likely to adopt a > ready-to-deploy solution than a theoretical proposal. But I'm > interesting in hearing more opinions first. > > > You could set up several servers/accounts > > That is not needed. Different lists can simply be different folders of > the same account. IMAP supports ignoring / subscribing to specific folders. Yes, I know. The separation I suggested (lists.d.o, lists.alioth.d.o and bugs.d.o) could be necessary because of scalability issues, not only in the server, but also in the clients: - lists.debian.org has 270 lists - bugs.debian.org is quickly approaching 80 bugs - alioth.debian.org hosts 1042 different projects (which may ar may not have one or more lists (there are 124 lists starting with debian- and another 660 lists starting with pkg-). Besides that you also have to consider some kind of message expiration and/or archiving, because even mutt takes a while to access my 'All Mail' folder on Gmail (35000+ messages). Hmm, your proposal could be a great way of reading the archives, especially when combined with something like notmuch for searching :) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Using PuTTY with Debian GNU/Linux Systems
On Sb, 11 oct 14, 07:34:06, Stephen Powell wrote: > The idea of a wiki article is to document how to use Debian, not how > to fix Debian. But I assume you did file bugs ;) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Using PuTTY with Debian GNU/Linux Systems
On Sat, 11 Oct 2014 08:44:51 -0400 (EDT), Andrei POPESCU wrote: > On Sat, 11 Oct 2014, 07:34:06 -0400 (EDT), Stephen Powell wrote: >> The idea of a wiki article is to document how to use Debian, not how >> to fix Debian. > > But I assume you did file bugs ;) Well, the fact that xterm-utf8 is missing from the dircolors database of terminals which support color is arguably a bug. It represents an inconsistency between two packages. ncurses says it supports color, coreutils says it doesn't. I haven't reported this as a bug yet, but I will, unless someone else has already done so. But my proposed new terminal type, xterm-256color-utf8, is arguably an enhancement request, not a bug. From my point of view, its absence represents a "bug" in that there is no terminal type definition which adequately describes my terminal. But from the package maintainer's point of view, it's an enhancement request. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1508629613.4045448.1413032827101.javamail.zim...@wowway.com
Re: alternative file systems
On 10/10/2014 10:20 PM, lee wrote: >> The license of ZFS makes it impossible to be part of >> the kernel per se. The DKMS system is well known for supporting kernel >> modules for video and wireless hardware among others. > So there isn't really any way to tell whether it works or not? Which > kernel version is ZFS based on/for? > > Btrfs wouldn't let me do RAID-5 --- perhaps 3.2 kernels are too old for > that? > > They need to get these license issues fixed ... There's a userland ZFS package (via Fuse) available in debian in the zfs-fuse package. It should be pretty much independent of kernel versions. -- The two most beautiful words in the English language are "Cheque Enclosed." -- Dorothy Parker Eduardo M KALINOWSKI edua...@kalinowski.com.br -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54393640.9010...@kalinowski.com.br
Re: Prolem with external monitor
On 11/10/2014, Andrei POPESCU wrote: > On Vi, 10 oct 14, 11:24:55, Bret Busby wrote: >> >> Can Debian 7 run an external monitor? > > Definitely, I'm using my TV as external monitor sometimes. Could you > please attach your Xorg.0.log? Inlining works as well if you take care > not to break long lines. > What is the path to that file? -- Bret Busby Armadale West Australia .. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of Book 1 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACX6j8NLV_P4aoVRQXn8aZOoWxR=qtafqhphzudxrfhd9qj...@mail.gmail.com
Re: question about systemd
Добрый день. -- С уважением, Олег Слабоспицкий консультант по ПО Oracle ЗАО РДТЕХ On Sat, 11 Oct 2014 15:24:09 +0300 Andrei POPESCU wrote: > On Sb, 11 oct 14, 15:56:02, Reco wrote: > > On Sat, 11 Oct 2014 13:53:20 +0300 > > Andrei POPESCU wrote: > > > > > > Linus Torvalds "only" created the Linux kernel, which is notoriously > > > monolithic[1]. > > > > > > [1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate > > > > Yet, being monolithic, it provides hugezillion compile options and lots > > of kernel modules which can be loaded and unloaded at user's pleasure. > > Therefore Linux kernel is about a choice :) > > $ ls /lib/systemd/systemd* | wc -l > 38 Upstream already did it for you - [1]. Actual maximum number is 69. And that's not compile options, that's number of resulting binaries. > (no, I won't be bothered to look up all systemd compile options) [2] shows actual compile options example. Not that much, I'd say. Comparing to the backported Debian Linux kernel 3.16 that's nothing: $ grep ^[A-Z] /boot/config-3.16-0.bpo.2-amd64 | wc -l 4437 So, my point stands. [1] http://0pointer.de/blog/projects/the-biggest-myths.html [2] http://www.linuxfromscratch.org/lfs/view/systemd/chapter06/systemd.html Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011191238.d52351823489a0e030fa6...@gmail.com
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi. On Sat, 11 Oct 2014 15:18:58 +0300 Andrei POPESCU wrote: > On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: > > > > Some complexities you can encapsulate or hide, or expose in an > > organized manner so that that are easier to deal with. Others, no. > > [big snip] > > The complexity argument can be used both ways: Indeed. In fact: > - the Unix way (do one thing and do it well) leads to many small tools > that can be combined in different ways, where each tool has its own > quirks, bugs, release schedules, etc. that only increase complexity On the other hand, full blown systemd comes with 69 binaries on board, and such number of binaries reduce complexity somehow :) > - sysvinit (/bin/init) is indeed quite simple, but in practice it's own > mechanisms (/etc/inittab) are only used to start sysv-rc > (/etc/init.d/rc) You're wrong. At least gettys are started via /etc/inittab, and Ctrl-Alt-Del handling goes there too. > , which starts all other initscripts, poorly written > (/etc/init.d/skeleton itself is known to have bugs) Every software more complex than 'Hello World' has bugs. Heck, *systemd* has bugs. > in a (poor) > programming language (shell script) As latest development of OpenSSL show us, C isn't that great programming language either, and more complex than shell. > with many different > implementations (bash, dash, etc.). As long as shell in question conforms with POSIX specification, it does not matter. And nobody forbids one to put a binary into /etc/init.d, it'll work. Or a Perl script. It's just a convention that everyone put shell scripts there. > The scrips are not even enough, > they have to rely on additional tools like start-stop-daemon(8) with > their own quirks and bugs. That's the intended usage of shell scripts - to be a glue between utilities. Does it surprise you? > - each service/daemon is implemented in its own unique way, with > different methods of running (quite often multiple ways, depending on > start-up switches, like foreground, forking, etc.), reloading, > logging, etc. Given that said 'services' are written by different people - that's nothing unusual. In fact, ever-growing DSL of systemd's units clearly shows that 'one size fits all' approach constantly fail to account for various corner cases. > - computers have gotten quite complex themselves with removable devices, > complex network connectivity, etc. 'Removable devices' could been news in 1980s. 'Complex network connectivity' usually requires one to configure a network interface or two, and start a bunch of helper daemons. It would be fair argument if systemd suite contained implementations of all VPN clients known to the man - but it does not. > - multiple users on the same system (GNU/Linux is supposed to be a > multiuser system, isn't it) with different backgrounds, level of > technical understanding, expectations, etc. Wait, wait, wait. You mean there was no multiuser systems based on GNU/Linux before systemd invention? Or said multiuser systems were unusable? > It feels to me like systemd (the project) is rather *trying* to reduce > complexity, by providing: > > - a clear and simple way (unit files) to declare what a service needs > and how it should be run and a clear and simple method for the daemon > to notify when it is ready to provide its service if its authors > choose to implement it By inventing its' own DSL [1] to write such unit files, therefore moving complexity from writing a shell script to learning constantly changing DSL. > - mechanisms to deal with badly behaved daemons as well as provide > proper isolation (e.g. cgroups, tmp files handling, etc.) You've probably meant 'using existing kernel mechanisms to deal with…'. > - mechanisms to deal with the complex interactions between daemons, > devices, networks, etc. Please provide an example of such interaction. And, while we're at it, a definition of a 'network' you're using here. > - a logging mechanism that can capture *all* output of a daemon (stdout, > stderr, logging) Which any daemon shouldn't have at all to start with. The very definition of daemon implies it detached own stdout, stderr and stdin. Systemd has couple of interesting tricks for starting daemons (ptrace, clearing environment, to name a few), but logging mechanism (aka journald) is an optional part of systemd. > - a unified way to manage users (as in humans) and their complex ways of > interacting with the computer (different privileges, local, remote, > etc.) Said unified way is unable to distinguish a user at the console from a user who's connecting to a computer by means of x11vnc :) Does not assign a 'seat' to the ssh-connected user. And is only good for a typical desktop. Clearly there's much work to be done here. [1] https://en.wikipedia.org/wiki/Domain-specific_language Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
Re: alternative file systems (was: Re: lvm: creating a snapshot)
Hi. On Sat, 11 Oct 2014 03:20:50 +0200 lee wrote: > > The license of ZFS makes it impossible to be part of > > the kernel per se. The DKMS system is well known for supporting kernel > > modules for video and wireless hardware among others. > > So there isn't really any way to tell whether it works or not? ZFS is out-of-tree kernel module. It *will* break sooner or later. Every out-of-tree module does. > Which > kernel version is ZFS based on/for? [1] tells us that ZFS on Linux verion 0.6.3 supports kernels 2.6.26 - 3.16. > Btrfs wouldn't let me do RAID-5 --- perhaps 3.2 kernels are too old for > that? A correct guess. A recommended minimum is kernel 3.14 - [2]. But, ZFS won't allow you to make a conventional RAID5 either :) > They need to get these license issues fixed ... Back in the old days CDDL was chosen by Sun especially so that this license issue would *never* be fixed. Currently Oracle could re-license ZFS to anything they want, including GPL-compatible license, but why would *they* do it? [1] http://zfsonlinux.org/faq.html [2] http://marc.merlins.org/perso/btrfs/post_2014-03-23_Btrfs-Raid5-Status.html Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011200842.20d2fb87091c4dbf160ca...@gmail.com
Re: implicit linkage
On 10/11/2014 08:18 AM, Andrei POPESCU wrote: Is systemd (the project) trying to do too much? Possibly. Would it be better if this was done in a modular design *done right*? Probably. Yet, none of the solutions so far has *really* caught on. daemontools, runit, s6, init-ng, etc. and even upstart were either never adopted on a large scale or eventually abandoned in favor of systemd. They also probably did not have dependency bundling and an $11B corporation behind them either. :) As far as I understand Linus Torvalds himself admits that a modular kernel design is better, yet he choose to make Linux monolithic. On the other hand Hurd is still not even in a releasable state. I don't think there's any question that modular is harder. It requires actual engineering, not systemd-style hacking. Even Windows experimented with a "microkernel" in the Cutler days, but ultimately seems to have settled back into bloatware, the path of least resistance. I also wonder if Linux has scaling issues, and how much corporate influence this causes and how much longer Linus can fend it off? Could it be that a modular design for such complex tasks becomes too difficult to *do it right*? I don't know, but I think given its history, the burden of proof is on monolithic, not modular design. A better question may be whether a distributed volunteer project can do real system architecture? (Where is CERN when you need them?) Is systemd going to change the GNU/Linux ecosystem? Definitely. Will this change be good or bad? Only time will tell, but I'm quite sure that even if the change will turn out to be bad it will *not* destroy GNU/Linux, but help it evolve in better ways. If nothing else it gives us a new low bar, a bogyman to replace Windows, which is seeing hard times, and now even resorts to copying Linux. :) Kind regards, Andrei -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54395891.2040...@ix.netcom.com
Re: Prolem with external monitor
On Sb, 11 oct 14, 23:09:20, Bret Busby wrote: > > > > Definitely, I'm using my TV as external monitor sometimes. Could you > > please attach your Xorg.0.log? Inlining works as well if you take care > > not to break long lines. > > What is the path to that file? /var/log/Xorg.0.log kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: How to do this ?
On Sat, 11 Oct 2014 13:38:05 +0300 Andrei POPESCU wrote: > On Vi, 10 oct 14, 19:51:50, Erwan David wrote: > > I want to have a system which boots, and starts a subset of daemons. > > > > Then afterward I ssh to it, do something which 1) mount an encrypted > > disk, 2) start other daemons (which depends on the encrypted disk). > > > > I know how to do this with policy-rc.d, how can I do this with > > systemd ? > > My first though on doing this with sysv-rc would have been runlevels, > why do you even need policy-rc.d? LOL, when I read the original question, I didn't answer because I thought he was inisting on a policy-rc solution. If policy-rc.d weren't required, and if it were me, the solution would be totally obvious, because I'm a daemontools type of guy... I'd put all the services to be started secondarily under daemontools. I'd have a directory somewhere, with empty filenames corresponding to the services I want to bring up secondarily: /home/slitt/servicelist or whatever. Then I'd make these shellscripts: # #!/bin/sh # this is uppp.sh if bring_up_encrypted_filesystem.sh; then for f in /home/slitt/servicelist; do rm -f /service/$f/down svc -u /service/$f done else handle_encrypt_up_error.sh fi # # #!/bin/sh # this is downnn.sh for f in /home/slitt/servicelist; do touch /service/$f/down svc -d /service/$f done if bring_down_encrypted_filesystem.sh; then poweroff else handle_encrypt_down_error.sh fi # Obviously I haven't tech-edited these, and also obvious I left a lot of stuff for the encrypted disk as an exercise for the reader, but basically: To boot up, you boot up, ssh in, and run uppp.sh To shut down, you ssh in, run downnn.sh. If you sometimes need to reboot instead of powering off, you could remove the shutdown from downnn.sh and just do it manually while you're ssh'ed in. HTH, SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011124548.15d40...@mydesq2.domain.cxm
Re: implicit linkage
On Sb, 11 oct 14, 12:19:29, Marty wrote: > > >Could it be that a modular design for such complex tasks becomes too > >difficult to *do it right*? > > I don't know, but I think given its history, the burden of proof is on > monolithic, not modular design. A better question may be whether a > distributed volunteer project can do real system architecture? (Where is > CERN when you need them?) Who's history, Linux' (the kernel)? :p Couldn't it be that the fact that so many are embracing the "monolithic" design of systemd is a sign that the modular design was... suboptimal and nobody came up with a better one? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: question about systemd
On Sb, 11 oct 14, 19:12:38, Reco wrote: > > Upstream already did it for you - [1]. Actual maximum number is 69. And > that's not compile options, that's number of resulting binaries. > > > > (no, I won't be bothered to look up all systemd compile options) > > [2] shows actual compile options example. Not that much, I'd say. > Comparing to the backported Debian Linux kernel 3.16 that's nothing: > > $ grep ^[A-Z] /boot/config-3.16-0.bpo.2-amd64 | wc -l > 4437 > > So, my point stands. That systemd doesn't have to deal with hardware? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: question about systemd
On Sat, 11 Oct 2014 13:53:20 +0300 Andrei POPESCU wrote: > On Vi, 10 oct 14, 06:57:18, PETER ZOELLER wrote: > > This is really ticking me off. We are becoming just like Microsoft > > that one size fits all. Linux has always been about choice and > > modularity and reconfigurability where a user or admin can choose > > that what suits him/her and the type of system they want. You want > > sysvinit you use Debian or Slackware, want Upstart go to Ubuntu, > > want systemd go to Fedora/Redhat. Where in all this is my choice > > to have my system boot via the means I or any user or admin > > considers to be the appropriate method to boot their system? > > What's wrong with you people? Have you lost sight of why Linus > > designed this system? Its about simplicity, modularity and > > reconfigurability. > > You might want to check your facts: > > Linus Torvalds "only" created the Linux kernel, which is notoriously > monolithic[1]. > > [1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate This is very true, but the kernel knows its boundaries, and doesn't try to conquor all sorts of other, non-related, subsystems. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011124915.4c8e3...@mydesq2.domain.cxm
Re: question about systemd
On Sat, Oct 11, 2014 at 7:38 AM, The Wanderer wrote: > On 10/10/2014 at 07:53 PM, James Ensor wrote: > >> On Fri, Oct 10, 2014 at 7:31 PM, John Hasler >> wrote: >> >>> James Ensor writes: >>> My impression is that the idea of "systemd's entanglement" has been blown way out of proportion. >>> >>> The entanglement discussed here earlier had to do with the design >>> of the Systemd suite, not with dependencies. > > (Well, there was some discussion about the dependencies side of thing as > well, but I think that's more an effect of the design of the systemd > suite rather than a primary issue of its own.) > >> Exactly, and that has been blown way out of proportion. You do not >> need to have systemd installed or running to have a usable >> Debian-testing install. > > Er... how do these two sentences make sense together? > > If I'm reading you correctly, you're claiming that the entanglement > involved in the design of the systemd suite has been blown way out of > proportion, and in support of that you're citing the fact that you do > not need to have systemd installed to have a usable Debian testing system. > > But whether or not you have to have systemd installed to have a usable > Debian testing system is not about the design of the systemd suite; it's > about dependencies. So your citation seems to have nothing to do with > the claim at hand. > > Is there something I'm missing that makes this make sense? > No, I don't think you are missing anything, I just did a really bad job at translating things from my head to my keyboard, and I confused two arguments Part of that is that I've lost track of who is saying what. In my original post, I just pointed out that it's easy to pick an init system other than systemd by purging it. I was just trying to be practical. Subsequent posts seemed to get wy off topic, uninformative, and possibly misleading about how many other things one would lose by removing systemd. I think someone even stated that, by removing systemd, a computer would be terrible for daily use. That's just false. What I was trying to say here is that people seem to want to debate the philosophy/quality/whatever about systemd, and have used this to come to wrong conclusions about the practical aspect of using an alternate init system. And, just for the record, I started this exercise just because I was curious what would happen if I removed systemd. I don't claim to understand all the complexities of init systems (as you have been able to tell). Honestly my system seemed to be working just fine with systemd, and it's working fine without it. I don't really have an opinion about it. Many of the opinions I have seen expressed in this thread seem to me to be based not on any facts or knowledge, but more on prejudice. Cheers, James -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAFXvjvD2+yZsRAEV5gmqiJ=cw8yf--6tctkgoor9itqhb1n...@mail.gmail.com
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sat, 11 Oct 2014 15:18:58 +0300 Andrei POPESCU wrote: > On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: > > > > Some complexities you can encapsulate or hide, or expose in an > > organized manner so that that are easier to deal with. Others, no. > > [big snip] > > The complexity argument can be used both ways: > > - the Unix way (do one thing and do it well) leads to many small > tools that can be combined in different ways, where each tool has its > own quirks, bugs, release schedules, etc. that only increase > complexity At first, yes. But over time these do-one-thing-and-do-it-well pieces become battle-hardened and fully tested, and they change very slowly. And, they're not subject to feature creep. > - sysvinit (/bin/init) is indeed quite simple, but in practice it's > own mechanisms (/etc/inittab) are only used to start sysv-rc > (/etc/init.d/rc), which starts all other initscripts, poorly > written (/etc/init.d/skeleton itself is known to have bugs) in a > (poor) programming language (shell script) with many different > implementations (bash, dash, etc.). The scrips are not even enough, > they have to rely on additional tools like start-stop-daemon(8) > with their own quirks and bugs. :-) sysvinit is an idea whose time has gone. sysvinit is a poor way to showcase the Unix Way. First of all, the whole idea of runlevels is bizarre, and adds a lot of complexity to init scripts. If you compare a daemontools /service/myserviced/run to an init script, you'll see an order of magnetude simplification, without sacrificing the flexibility of a shellscript. > > - each service/daemon is implemented in its own unique way, with > different methods of running (quite often multiple ways, depending > on start-up switches, like foreground, forking, etc.), reloading, > logging, etc. Daemontools, and I'd assume all the PID1 softwares based on daemontools, handles the backgroundization itself. So you just use a flag to run your daemon in the foreground, and it's taken care of. For those developers who insist on making their lives difficult by backgrounding it themselves, with no foreground switch, daemontools includes a program which *sometimes* can foregroundize the backgroundized service, although obviously the real way to do it is to have the original programmer provide a way to run his program in the foreground. > > - computers have gotten quite complex themselves with removable > devices, complex network connectivity, etc. > > - multiple users on the same system (GNU/Linux is supposed to be a > multiuser system, isn't it) with different backgrounds, level of > technical understanding, expectations, etc. > > It feels to me like systemd (the project) is rather *trying* to > reduce complexity, by providing: > > - a clear and simple way (unit files) to declare what a service needs > and how it should be run and a clear and simple method for the > daemon to notify when it is ready to provide its service if its > authors choose to implement it > > - mechanisms to deal with badly behaved daemons as well as provide > proper isolation (e.g. cgroups, tmp files handling, etc.) > > - mechanisms to deal with the complex interactions between daemons, > devices, networks, etc. > > - a logging mechanism that can capture *all* output of a daemon > (stdout, stderr, logging) > > - a unified way to manage users (as in humans) and their complex ways > of interacting with the computer (different privileges, local, > remote, etc.) I *might* characterize the preceding as trying to reduce complexity for the dufus who can't even write a shellscript. However, the cost of this reduced complexity for the dufus is huge complexity within the program: complexity even smart people can't work around without some truly ridiculous kludges. Also, and this is just my opinion, reducing complexity is not what I think Red Hat is trying to do. I think they're trying to make an operating system so complex that their help is necessary for anything but the most plain vanilla installations, and they're trying to create a Linux ecosystem where all distributions must march to the Red Hat drummer, with the ultimate goal of monopolism and divergence from standards (POSIX for one). Like I said, this is my opinion. You might say "Hanlon's razor", and I'd reply "follow the money." > > - etc. > > Is systemd (the project) trying to do too much? Possibly. :-) Nice understatement. > Would it be better if this was done in a modular design *done right*? > Probably. I'd say modular design done right would be for systemd to be PID1 and nothing else. It should be able to accept all PAM implementations currently accepted. It shouldn't need to subsume all sorts of other OS functions. And if that were the case, it would be done already, with not a bit of resistance from users. > > Yet, none of the solutions so far has *really* caught on. > daemontools, runit, s6, init-ng, etc. and even upstart were either > neve
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sb, 11 oct 14, 19:57:42, Reco wrote: > On Sat, 11 Oct 2014 15:18:58 +0300 > Andrei POPESCU wrote: > > > On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: > > > > > > Some complexities you can encapsulate or hide, or expose in an > > > organized manner so that that are easier to deal with. Others, no. > > > > [big snip] > > > > The complexity argument can be used both ways: > > Indeed. In fact: > > > > - the Unix way (do one thing and do it well) leads to many small tools > > that can be combined in different ways, where each tool has its own > > quirks, bugs, release schedules, etc. that only increase complexity > > On the other hand, full blown systemd comes with 69 binaries on board, > and such number of binaries reduce complexity somehow :) coreutils alone has 107 binaries. > > - sysvinit (/bin/init) is indeed quite simple, but in practice it's own > > mechanisms (/etc/inittab) are only used to start sysv-rc > > (/etc/init.d/rc) > > You're wrong. At least gettys are started via /etc/inittab, and > Ctrl-Alt-Del handling goes there too. Oh yes, forgot about that. But my point still stands: why is (almost) nobody using /etc/inittab to manage their services? > > , which starts all other initscripts, poorly written > > (/etc/init.d/skeleton itself is known to have bugs) > > Every software more complex than 'Hello World' has bugs. Heck, > *systemd* has bugs. Yes, but with initscripts you can get slightly different version of the same bug (e.g. depending on which version of 'skeleton' they are based on, the script-fu of the respective maintainer, the phase of the moon, etc), but much more difficult to fix, because you have to inspect each package. At least with systemd if you fix a bug it will benefit all daemons using it. This is the same reason we are using shared libraries and the Debian Security Team is doing it's best to track code copies. The recent method of using a common script goes in the right direction though. > > in a (poor) > > programming language (shell script) > > As latest development of OpenSSL show us, C isn't that great > programming language either, and more complex than shell. Sure, but at least a lot of eyeballs are looking at it. How many eyes do you think look at the average initscript? > > with many different > > implementations (bash, dash, etc.). > > As long as shell in question conforms with POSIX specification, it does > not matter. And nobody forbids one to put a binary into /etc/init.d, > it'll work. Or a Perl script. It's just a convention that everyone put > shell scripts there. You're right, I just went through Policy 9.3 and can't find it explicitly stated that scripts in /etc/init.d/ should be shell scripts, but it seems to be an implicit assumption (ha!). > > The scrips are not even enough, > > they have to rely on additional tools like start-stop-daemon(8) with > > their own quirks and bugs. > > That's the intended usage of shell scripts - to be a glue between > utilities. Does it surprise you? Nope, it just proves my point that sysv-rc is *very* complex. > > - each service/daemon is implemented in its own unique way, with > > different methods of running (quite often multiple ways, depending on > > start-up switches, like foreground, forking, etc.), reloading, > > logging, etc. > > Given that said 'services' are written by different people - that's > nothing unusual. In fact, ever-growing DSL of systemd's units clearly > shows that 'one size fits all' approach constantly fail to account for > various corner cases. Such as? > > - computers have gotten quite complex themselves with removable devices, > > complex network connectivity, etc. > > 'Removable devices' could been news in 1980s. True, but sysv-rc still can't deal with them correctly. > 'Complex network connectivity' usually requires one to configure a > network interface or two, and start a bunch of helper daemons. It would > be fair argument if systemd suite contained implementations of all VPN > clients known to the man - but it does not. I'll just give my laptop as example: I have wired & wireless at home, other wired/wireless network if I take my laptop around plus a dongle for mobile. And then there's IPv6 (coming... is... coming... whatever). > > - multiple users on the same system (GNU/Linux is supposed to be a > > multiuser system, isn't it) with different backgrounds, level of > > technical understanding, expectations, etc. > > Wait, wait, wait. You mean there was no multiuser systems based on > GNU/Linux before systemd invention? Or said multiuser systems were > unusable? No, that was just for the "I'm sole user of this system, why would I need this logind stuff?" crowd. > > It feels to me like systemd (the project) is rather *trying* to reduce > > complexity, by providing: > > > > - a clear and simple way (unit files) to declare what a service needs > > and how it should be run and a clea
Re: question about systemd
On Sat 11 Oct 2014 at 07:38:42 -0400, The Wanderer wrote: > On 10/10/2014 at 07:53 PM, James Ensor wrote: > > > On Fri, Oct 10, 2014 at 7:31 PM, John Hasler > > wrote: > > > >> James Ensor writes: > >> > >>> My impression is that the idea of "systemd's entanglement" has > >>> been blown way out of proportion. > >> > >> The entanglement discussed here earlier had to do with the design > >> of the Systemd suite, not with dependencies. > > (Well, there was some discussion about the dependencies side of thing as > well, but I think that's more an effect of the design of the systemd > suite rather than a primary issue of its own.) > > > Exactly, and that has been blown way out of proportion. You do not > > need to have systemd installed or running to have a usable > > Debian-testing install. > > Er... how do these two sentences make sense together? > > If I'm reading you correctly, you're claiming that the entanglement > involved in the design of the systemd suite has been blown way out of > proportion, and in support of that you're citing the fact that you do > not need to have systemd installed to have a usable Debian testing system. > > But whether or not you have to have systemd installed to have a usable > Debian testing system is not about the design of the systemd suite; it's > about dependencies. So your citation seems to have nothing to do with > the claim at hand. > > Is there something I'm missing that makes this make sense? 1. The design of systemd is thought to have certain consequences which may have an inpact on a Debian system. 2. One consequence of the design is that there are 'entanglements' when it comes to installing packages on Debian. 'Entanglements' are simply dependencies. Debian has a package system which has relied on the concept of dependencies for many. many years. Inventing a new term for a familiar process doesn't appear helpful. 3. The consequence in 2. is a major consequence of the perceived design limitation in systemd . It might actually be the only one of practical importance to users installing and managing a Debian system. 4. It is an undisputed fact that testing and unstable users can remove systemd absurdly easily. 5. The practical outcome of 4. and 3. is that the proposition in 1. is of little importance to Debian users. Most are only concerned with 'Does it work?'. 'It does indeed' is the answer. These users have little interest in perusing the design of systemd. Even if it didn't work as well as it does they would still have no interest. The design aspect is trumped by reality; hammering away at it doesn't increase its significance. 6. A number of users want a different init system. Are they catered for? Of course they are! Please see 4. 1. was discussed earlier this year. A decision was made. Reprising it in debian-user may produce some clarification but the fundamental framework for Jessie has been laid down. And to illustrate how much work Debian maintainers put in to respond to users' concerns: root@gnome-jessie:~# apt-get install sysvinit-core systemd-shim Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: cgmanager libcgmanager0 libnih-dbus1 libnih1 Suggested packages: pm-utils The following packages will be REMOVED: systemd-sysv The following NEW packages will be installed: cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim sysvinit-core 0 upgraded, 6 newly installed, 1 to remove and 0 not upgraded. Need to get 482 kB of archives. After this operation, 1,030 kB of additional disk space will be used. Do you want to continue? [Y/n] What more could a Debian user want? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011174112.ga17...@copernicus.demon.co.uk
Using device UUSBs with cryptsetup to open already encrypted USB sticks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The command syntax for opening such a device is sudo cryptsetup luksOpen As I understand the syntax, the device designation can be /dev/sd?? where the first question mark is the third letter of the device selected by the OS, and the second question mark is the partition number. Since device designation in this way is not constant I would like to use the UUID of the device instead of having to check beforehand which sd desognation the OS chose when each such stick is attached to the computer. Running sudo blkid -L I found the UUIDs for each stick which are quite long, e.g., UUID="65e7697c-d5fa-4e16-84e9-c45d2f81dd69". I assume I can somehow use such a UUID to indicate the device instead /dev/sd??, but I cannot figure out how. The cryptsetup man page does not say how, nor could I find out how by googling. If I knew how I could create individual script files to open and close each stick. I would be using the bash shell for such scripts. (The script would also include the mount/unmount command by using the - UUID assigned to each stick after access to it is opened.) I would consequently appreciate it if someone could tell me how. Regards, Ken Heard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlQ5c5AACgkQlNlJzOkJmTcl5wCfRoOH8GJboWcdR7RDFHIZYXQw 4ogAnRODg4/HaT2YmQYDrgtwizzn78WT =oorg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54397390.6040...@teksavvy.com
Re: question about systemd
* On 2014 11 Oct 12:11 -0500, Steve Litt wrote: > On Sat, 11 Oct 2014 13:53:20 +0300 > Andrei POPESCU wrote: > > You might want to check your facts: > > > > Linus Torvalds "only" created the Linux kernel, which is notoriously > > monolithic[1]. > > > > [1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate > > This is very true, but the kernel knows its boundaries, and doesn't try > to conquor all sorts of other, non-related, subsystems. Also, the kernel developers have moved some things out of the kernel over the years, IIUC. This is the question I have, what are the stated boundaries of the systemd project? Have any boundaries/goals been stated in terms of when systemd will be feature complete? What is the stated compliance to POSIX (Google doesn't seem to provide me good results)? I realize that no distribution will ever be formally POSIX compliant but I always thought it was a good goal to work toward. I really don't want to see the community abandon POSIX compliance. No, POSIX is not perfect and has received a number of revisions over the years. Without some kind of goal posts development will be all over the map. It seems we're looking at a similar situation today as then which begat POSIX as an effort to bring some order to the UNIX world a few decades ago. I fear that we are living the axiom, "Those who do not understand UNIX are condemned to reinvent it, poorly." - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011180012.ga5...@n0nb.us
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sb, 11 oct 14, 13:40:08, Steve Litt wrote: > > sysvinit is an idea whose time has gone. sysvinit is a poor way to > showcase the Unix Way. First of all, the whole idea of runlevels is > bizarre, and adds a lot of complexity to init scripts. If you > compare a daemontools /service/myserviced/run to an init script, you'll > see an order of magnetude simplification, without sacrificing the > flexibility of a shellscript. Why should I write a script? I'm not a programmer. [snip] > I *might* characterize the preceding as trying to reduce complexity for > the dufus who can't even write a shellscript. However, the cost of this > reduced complexity for the dufus is huge complexity within the program: > complexity even smart people can't work around without some truly > ridiculous kludges. I can write a (simple) shellscript, but I wouldn't dare write an initscript or even a daemontools runscript. > I have a theory on that. runit, s6, init-ng, etc never caught on > because sysvinit was considered good enough, and it was easier for the > average person to work around its rough edges rather than learn a new > init system. I recently needed something to run imapfilter and restart it in case it might exit, so I had a look at daemontools. I gave up quickly after I realised the amount of scaffolding required just to get daemontools itself running (additional top-level directories, are you kidding?). With systemd (v215) I had to write this unit file: ,[ .config/systemd/user/imapfilter.service ] | [Unit] | Description=Unit to run imapfilter | | [Service] | Type=simple | ExecStart=/usr/bin/imapfilter | Restart=always | | [Install] | WantedBy=default.target ` $ systemctl --user start imapfilter # to start it right away $ systemctl --user enable imapfilter # to have it start automatically on login (optional) # systemctl enable-linger # to enable my 'systemd --user' instance to run even if I'm not logged in. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: How to do this ?
> On 10 Oct 2014, at 18:51, Erwan David wrote: > > how can I do this with systemd ? You'd write a systemd unit for the mount operation (there's a mount type) which wasn't hooked into the default multiuser target. You'd then make the depending daemons have service files which depended on that mount unit (as oppose to multilevel). Specifics left as an exercise for now (on phone not laptop) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/470de002-6c7f-430c-8ad5-13e2fe564...@debian.org
Re: question about systemd
Hi. On Sat, 11 Oct 2014 19:41:31 +0300 Andrei POPESCU wrote: > On Sb, 11 oct 14, 19:12:38, Reco wrote: > > > > Upstream already did it for you - [1]. Actual maximum number is 69. And > > that's not compile options, that's number of resulting binaries. > > > > > > > (no, I won't be bothered to look up all systemd compile options) > > > > [2] shows actual compile options example. Not that much, I'd say. > > Comparing to the backported Debian Linux kernel 3.16 that's nothing: > > > > $ grep ^[A-Z] /boot/config-3.16-0.bpo.2-amd64 | wc -l > > 4437 > > > > So, my point stands. > > That systemd doesn't have to deal with hardware? No, that the kernel grants you all kinds of choices. Of course systemd deals with hardware, it ships udev for that specific task. Whenever it should deal with the hardware is another question. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011220843.6a040a249f0cf9ef2da81...@gmail.com
Re: question about systemd
Ahoj, Dňa Sat, 11 Oct 2014 18:41:12 +0100 Brian napísal: > And to illustrate how much work Debian maintainers put in to respond > to users' concerns: > > root@gnome-jessie:~# apt-get install sysvinit-core systemd-shim > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following extra packages will be installed: > cgmanager libcgmanager0 libnih-dbus1 libnih1 > Suggested packages: > pm-utils > The following packages will be REMOVED: > systemd-sysv > The following NEW packages will be installed: > cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim > sysvinit-core 0 upgraded, 6 newly installed, 1 to remove and 0 not > upgraded. Need to get 482 kB of archives. > After this operation, 1,030 kB of additional disk space will be > used. Do you want to continue? [Y/n] > > What more could a Debian user want? I don't know what other users want, but i tried it some days ago (when the latest version of the systemd comes into testing) and i want e.g. to be able to reboot, shutdown, suspend and hibernate the machine as regular user from my XFCE session. That is all, what i want and when i try it, i get message about insufficient permissions. I ask here for help, but no one (i expect the response especially from these who tells, that this ML is for support not for discussion) give me the solution how to get the sufficient permissions back. regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: question about systemd
On Sb, 11 oct 14, 13:01:38, James Ensor wrote: > > And, just for the record, I started this exercise just because I was > curious what would happen if I removed systemd. I don't claim to > understand all the complexities of init systems (as you have been able > to tell). Honestly my system seemed to be working just fine with > systemd, and it's working fine without it. I don't really have an > opinion about it. Many of the opinions I have seen expressed in this > thread seem to me to be based not on any facts or knowledge, but more > on prejudice. Agreed. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: question about systemd
On Sat 11 Oct 2014 at 13:01:38 -0400, James Ensor wrote: > No, I don't think you are missing anything, I just did a really bad > job at translating things from my head to my keyboard, and I confused > two arguments Part of that is that I've lost track of who is > saying what. > > In my original post, I just pointed out that it's easy to pick an init > system other than systemd by purging it. I was just trying to be > practical. You will notice that not a single person has disputed this. The argument has instead been shifted to something else. Avoid agreement is the name of the game. > Subsequent posts seemed to get wy off topic, uninformative, and > possibly misleading about how many other things one would lose by > removing systemd. I think someone even stated that, by removing > systemd, a computer would be terrible for daily use. That's just > false. Of course it is, but when there is an agenda.. > What I was trying to say here is that people seem to want to debate > the philosophy/quality/whatever about systemd, and have used this to > come to wrong conclusions about the practical aspect of using an > alternate init system. It's only some people. Mind you, they have managed to generate some 1,000 posts in fighting yesterday's battles and ignoring reality. > And, just for the record, I started this exercise just because I was > curious what would happen if I removed systemd. I don't claim to > understand all the complexities of init systems (as you have been able > to tell). Honestly my system seemed to be working just fine with > systemd, and it's working fine without it. I don't really have an > opinion about it. Many of the opinions I have seen expressed in this > thread seem to me to be based not on any facts or knowledge, but more > on prejudice. Too practical. :) Why use something which is available in preference to something which doesn't exist? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/11102014191736.8d72aebea...@desktop.copernicus.demon.co.uk
Re: Nvidia No GLX to using OpenGL...
Op Sat, 11 Oct 2014 12:51:44 +0200 schreef Gábor Hársfalvi : Of course I already installed nvidia-glx. sudo apt-show-versions | grep nvidia sudo: apt-show-versions: command not found it look like you have to install apt-show-versions run: $ sudo apt-get install apt-show-versions $ apt-show-versions | grep nvidia (sudo isn't necessary for apt-show-versions) and could you post your /var/log/Xorg.0.log? success, floris Ps. reply to the list, so other people can help
Re: question about systemd
On Sat 11 Oct 2014 at 12:49:15 -0400, Steve Litt wrote: > On Sat, 11 Oct 2014 13:53:20 +0300 > Andrei POPESCU wrote: > > > You might want to check your facts: > > > > Linus Torvalds "only" created the Linux kernel, which is notoriously > > monolithic[1]. > > > > [1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate > > This is very true, but the kernel knows its boundaries, and doesn't try > to conquor all sorts of other, non-related, subsystems. What does that mean? It sounds deep but plumbing the depths of its shallowness is a task for someone with more time than the universe has got. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/11102014194942.1eb584bf4...@desktop.copernicus.demon.co.uk
Re: implicit linkage
Andrei POPESCU writes: > With systemd (v215) I had to write this unit file: Which is about as complex as filling out the skeleteon script to create an initscript to do the same thing. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87siiua0a3@thumper.dhh.gt.org
Re: question about systemd
On 11/10/14 19:00, Nate Bargmann wrote: This is the question I have, what are the stated boundaries of the systemd project? Have any boundaries/goals been stated in terms of when systemd will be feature complete? What is the stated compliance to POSIX (Google doesn't seem to provide me good results)? In respect of the first two questions: I am not aware of any such firm statements having been made. In respect of your third question: Contrary to the implicit expectation that seems to be attached to this question, POSIX.1-2008 appears to have very little to say about how any of the things systemd does are supposed to work. For example, one might expect that since the System Interfaces volume of POSIX.1-2008 stipulates the existence of the syslog() library function, it might say something about the nature of system logging. What it turns out to say is: "The syslog() function shall send a message to an implementation-defined logging facility, which may log it in an implementation-defined system log, write it to the system console, forward it to a list of users, or forward it to the logging facility on another host over the network. The logged message shall include a message header and a message body. The message header contains at least a timestamp and a tag string." (quoted from http://pubs.opengroup.org/onlinepubs/9699919799/functions/syslog.html ) I believe the journal constitutes a compliant back-end to POSIX syslog(), no doubt much to many people's disgust. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54397ef6.7030...@zen.co.uk
Re: question about systemd
On Sat 11 Oct 2014 at 20:06:14 +0200, Slavko wrote: > Ahoj, > > Dňa Sat, 11 Oct 2014 18:41:12 +0100 Brian > napísal: > > > What more could a Debian user want? > > I don't know what other users want, but i tried it some days ago (when > the latest version of the systemd comes into testing) and i want e.g. to > be able to reboot, shutdown, suspend and hibernate the machine as > regular user from my XFCE session. That is all, what i want and when i > try it, i get message about insufficient permissions. > > I ask here for help, but no one (i expect the response especially from > these who tells, that this ML is for support not for discussion) give > me the solution how to get the sufficient permissions back. Is your installation (wheezy/testing/unstable) completely up-to-date? The last time you posted you were working with something which had no relationship with Debian as we know it. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/11102014195959.f6cc6403f...@desktop.copernicus.demon.co.uk
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi. On Sat, 11 Oct 2014 20:47:36 +0300 Andrei POPESCU wrote: > On Sb, 11 oct 14, 19:57:42, Reco wrote: > > On Sat, 11 Oct 2014 15:18:58 +0300 > > Andrei POPESCU wrote: > > > > > On Vi, 10 oct 14, 08:36:23, Joel Rees wrote: > > > > > > > > Some complexities you can encapsulate or hide, or expose in an > > > > organized manner so that that are easier to deal with. Others, no. > > > > > > [big snip] > > > > > > The complexity argument can be used both ways: > > > > Indeed. In fact: > > > > > > > - the Unix way (do one thing and do it well) leads to many small tools > > > that can be combined in different ways, where each tool has its own > > > quirks, bugs, release schedules, etc. that only increase complexity > > > > On the other hand, full blown systemd comes with 69 binaries on board, > > and such number of binaries reduce complexity somehow :) > > coreutils alone has 107 binaries. Yup. Please calculate how many of them are actually used in /etc/init.d. You'll lower your number by the point of magnutude. Besides, coreutils is an essential package in Debian, systemd is not. > > > - sysvinit (/bin/init) is indeed quite simple, but in practice it's own > > > mechanisms (/etc/inittab) are only used to start sysv-rc > > > (/etc/init.d/rc) > > > > You're wrong. At least gettys are started via /etc/inittab, and > > Ctrl-Alt-Del handling goes there too. > > Oh yes, forgot about that. But my point still stands: why is (almost) > nobody using /etc/inittab to manage their services? Because one does not start services only, one sometimes needs to stop them. That's something that dbus people didn't learn in all these years, it seems. > > > , which starts all other initscripts, poorly written > > > (/etc/init.d/skeleton itself is known to have bugs) > > > > Every software more complex than 'Hello World' has bugs. Heck, > > *systemd* has bugs. > > Yes, but with initscripts you can get slightly different version of the > same bug (e.g. depending on which version of 'skeleton' they are based > on, the script-fu of the respective maintainer, the phase of the moon, > etc), but much more difficult to fix, because you have to inspect each > package. And with systemd you can have the same based on the same criteria. I mean, do you really expect a sane behavior from the project with a code quality like this - [1]? > At least with systemd if you fix a bug it will benefit all daemons using > it. No, quite the contrary. By fixing such jack-of-all-trades libsystemd library you're risking to *break* some other daemons. But, pretending your point is valid, fixing /etc/init.d/skeleton grants the same benefits. > This is the same reason we are using shared libraries and the Debian > Security Team is doing it's best to track code copies. Consider /etc/init.d/skeleton a library then. It's sources to any /etc/init.d script anyway. > The recent method of using a common script goes in the right direction > though. > > > > in a (poor) > > > programming language (shell script) > > > > As latest development of OpenSSL show us, C isn't that great > > programming language either, and more complex than shell. > > Sure, but at least a lot of eyeballs are looking at it. How many eyes do > you think look at the average initscript? As recent 'shellshock' vulnerability shows, many eyeballs are good, but hardly enough (hint - shellshock was introduced in 1989). And it also shows, that there're curious minds that are finding bugs everywhere, including shell scripts. Especially now, after shellshock 'fired'. > > > The scrips are not even enough, > > > they have to rely on additional tools like start-stop-daemon(8) with > > > their own quirks and bugs. > > > > That's the intended usage of shell scripts - to be a glue between > > utilities. Does it surprise you? > > Nope, it just proves my point that sysv-rc is *very* complex. Hardly. It proves that starting daemons is complex. Sysv-rc is simple by itself, and that's about the only good thing that can be said about sysv-rc IMO. > > > - each service/daemon is implemented in its own unique way, with > > > different methods of running (quite often multiple ways, depending on > > > start-up switches, like foreground, forking, etc.), reloading, > > > logging, etc. > > > > Given that said 'services' are written by different people - that's > > nothing unusual. In fact, ever-growing DSL of systemd's units clearly > > shows that 'one size fits all' approach constantly fail to account for > > various corner cases. > > Such as? Please see an arbitrary systemd's changelog. Observe phrases such as "we've added phrase FooBar to the unit files". Such phrases are the sign of DSL change, and it only happen for two reasons: a) Sudden irresistible urge (or voices in someone's head) to add a phrase. b) There's some daemon that genuinely need it. I prefer explanation b), what about you? > > > - computers have gotten quite
Re: Nvidia No GLX to using OpenGL...
Thanks for the help! apt-show-versions | grep nvidia libgl1-nvidia-alternatives/squeeze uptodate 195.36.31-6squeeze2 libglx-nvidia-alternatives/squeeze uptodate 195.36.31-6squeeze2 nvidia-kernel-2.6.32-5-486/squeeze uptodate 195.36.31+4+6squeeze2+2.6.32-45 nvidia-kernel-2.6.32-5-686-bigmem 195.36.31-6squeeze2+2.6.32-48squeeze8 newer than version in archive nvidia-kernel-common/squeeze uptodate 20100522+1 nvidia-kernel-source/squeeze uptodate 195.36.31-6squeeze2 nvidia-settings/squeeze uptodate 195.36.24-1 nvidia-vdpau-driver/squeeze uptodate 195.36.31-6squeeze2 nvidia-xconfig/squeeze uptodate 195.36.31-1 2014-10-11 20:55 GMT+02:00 Floris : > Op Sat, 11 Oct 2014 12:51:44 +0200 schreef Gábor Hársfalvi < > hgab...@gmail.com>: > > Of course I already installed nvidia-glx. > > sudo apt-show-versions | grep nvidia > sudo: apt-show-versions: command not found > > > it look like you have to install apt-show-versions > run: > > $ sudo apt-get install apt-show-versions > $ apt-show-versions | grep nvidia > (sudo isn't necessary for apt-show-versions) > > and could you post your /var/log/Xorg.0.log? > > success, > > floris > > Ps. reply to the list, so other people can help >
Re: question about systemd
On Sat 11 Oct 2014 at 13:00:12 -0500, Nate Bargmann wrote: > I fear that we are living the axiom, "Those who do not understand UNIX > are condemned to reinvent it, poorly." That is a misquote. Understandable when it is all over the web and comes up with a search engine, so don't worry about it. It should be "Those who do not understand systemd are condemned to reinvent it, poorly." -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/11102014200741.190fad81c...@desktop.copernicus.demon.co.uk
Re: implicit linkage
On Sb, 11 oct 14, 14:12:20, John Hasler wrote: > Andrei POPESCU writes: > > With systemd (v215) I had to write this unit file: > > Which is about as complex as filling out the skeleteon script to create > an initscript to do the same thing. Really? How do you write an initscript that restarts your daemon automatically in case it fails for some reason? Also, imapfilter doesn't write a pidfile at all, so I'd need to make at least some modifications to the script. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Using PuTTY with Debian GNU/Linux Systems
On Sat, Oct 11, 2014 at 07:34:06AM -0400, Stephen Powell wrote: > > In response to encouragement from several people on this list, > I have published a new web page titled "Using PuTTY with Debian > GNU/Linux Systems". It is available here: > >http://users.wowway.com/~zlinuxman/putty.htm > > All feedback, both positive and negative, is welcome. In particular, > if there are any factual errors on this page, I especially want to > know about that. Hello Stephen, thanks for your web page. I like how you research things in detail, also enjoyed your work on custom Linux kernels and their interaction with bootloader configuration some years ago. In your current article, you suggest rebuilding ncurses to add a custom terminal type. I find it much easier to just install a terminal definition locally as a configuration file. This can be achieved with the following command: tic -x terminaldef.src where terminaldef.src contains just the single entry from your patch. The output is written to /etc/terminfo/ or $HOME/.terminfo/, depending on the privileges of the user the tic command runs as. The ncurses library searches for terminal definitions in several places, including these two directories. Regards, Mirko -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011192333.GA15412@guitar.localdomain
Re: question about systemd
Hi. On Sat, 11 Oct 2014 20:11:57 +0100 Brian wrote: > On Sat 11 Oct 2014 at 13:00:12 -0500, Nate Bargmann wrote: > > > I fear that we are living the axiom, "Those who do not understand UNIX > > are condemned to reinvent it, poorly." > > That is a misquote. Understandable when it is all over the web and comes > up with a search engine, so don't worry about it. It should be > > "Those who do not understand systemd are condemned to reinvent >it, poorly." You misquote it too. An original quote was: "Those who do not understand Solaris SMF are condemned to reinvent it, with systemd, poorly." Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011233830.30f7c07dff50245df1464...@gmail.com
Re: question about systemd
On Sat, Oct 11, 2014 at 12:16:57AM +0100, Brian wrote: > On Fri 10 Oct 2014 at 15:31:35 -0700, Bob Holtzman wrote: > > > On Fri, Oct 10, 2014 at 12:16:23PM -0400, James Ensor wrote: > > > Please reply to the list and not directly to me. > > > > > > > > > On Fri, Oct 10, 2014 at 11:39 AM, PETER ZOELLER > > > wrote: > > > > Hi: > > > > > > > > I'm sorry but I shouldn't have to remove systemd but be given a choice > > > > as to > > > > which one I want at the time of the install just as I choose my file > > > > system, > > > > my software, my networking, where I want my boot loader installed, etc. > > > > To > > > > assume on your part what I need or want and then expect me to counter > > > > your > > > > choice by requiring me to uninstall is rather presumptuous on your part > > > > just > > > > the same approach that I would expect from Microsoft not Linux. > > > > > > > > Peter > > > > > > > > > > I made no assumptions, as I had absolutely nothing to do with the > > > decision of making systemd the default init system. I merely point > > > out that it is possible (and quite easy) for a debian-user to remove > > > systemd. > > > > What about systemd's entanglement? From what I read here, once it's > > installed there are certain programs that depend on it. Not true? > > You are approaching this the wrong way. > > James Ensor claims it is possible and easy for a user to remove systemd. > Your task is to show that is not; preferably by giving a concrete > technical example. > > Your mission is not to repeat some of the nonsense you may have read on > debian-user, query the veracity of those statements and then ask someone > to comment on your beliefs. > > Constructive contributions *to the topic* are always welcome. I don't have a task or a mission here. I simply asked a question. -- Bob Holtzman Giant intergalactic brain-sucking hyperbacteria came to Earth to rape our women and create a race of mindless zombies. Look! It's working! signature.asc Description: Digital signature
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sb, 11 oct 14, 23:20:34, Reco wrote: > On Sat, 11 Oct 2014 20:47:36 +0300 > Andrei POPESCU wrote: > > > At least with systemd if you fix a bug it will benefit all daemons using > > it. > > No, quite the contrary. By fixing such jack-of-all-trades > libsystemd library you're risking to *break* some other daemons. > But, pretending your point is valid, fixing /etc/init.d/skeleton grants > the same benefits. Nope. > > This is the same reason we are using shared libraries and the Debian > > Security Team is doing it's best to track code copies. > > Consider /etc/init.d/skeleton a library then. It's sources to > any /etc/init.d script anyway. No, it doesn't. > > True, but sysv-rc still can't deal with them correctly. > > It does not have to deal with the hardware, as it not its' job. It has to mount filesystems. > Ok. You have wired, that's one stanza in /etc/network/interfaces. Or > one obscure systemd's unit, if you prefer *that*. > You have wireless, and while it's possible to > use /etc/network/interfaces for that too (I do, for example), Joe the > Average User would probably use NetworkDestroyer (sorry, Manager), or > wicd. Anyway, wireless requires usage of wpa_supplicant, which is not a > part of systemd. Presumably one can use a systemd's unit for that too, > but I've never tried it. > A dongle for a mobile is probably a good old g_ether network interface > aka usb0. It's complicated somewhat as one may need to use > usb-modeswitch (not a part of systemd, btw), but it's nothing more > complex than yet another stanza in /etc/network/interfaces. > As for the IPv6 - unless you're turning your own PC into a router, > configuring IPv6 is something that kernel does for you already without > any intervention from the userspace (it's called a Router Advertisment). My point was that userspace has to react to changes in networking. The following might also provide for an interested read: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ > You don't have to, in this specific case. NFS should be mounted long > before any daemon starts, mpd included. Things can break, as your > example show. > A better example would be 'how I can ensure that mpd will > stop if I unmount a NFS share?'. > Still, I agree that's a valid point, *if* you disregard an existence > of automount(5). Because, mounting NFS from an fstab is *so* AIX. Why should I need to install yet another daemon, with yet another configuration file/syntax? > [3] tells us "systemd 30 and newer include systemd-logind. This is a > tiny daemon that manages user logins and seats in various ways." > I had an impression that an ssh login is an actual login. > And, since you can easily start an X session over ssh - there's need to > consider it a ssh login a seat too. Are you talking about X forwarding? Isn't the X session on the ssh client side (a.k.a. the X server side)? > As for the x11vnc - I doubt that it could be fixed. x11vnc attaches to > an existing X server, and is translating said server I/O over VNC to > anyone. It does not spawn its' own session, so there's nothing that can > be tracked. According to the package description it has "UNIX account and password" support. If that is done via pam (how else?) it should be possible for it to use libpam-logind. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Using PuTTY with Debian GNU/Linux Systems
On Sat, 11 Oct 2014 15:23:34 -0400 (EDT), Mirko Parthey wrote: > > In your current article, you suggest rebuilding ncurses to add a > custom terminal type. I find it much easier to just install a terminal > definition locally as a configuration file. > > This can be achieved with the following command: > tic -x terminaldef.src > where terminaldef.src contains just the single entry from your patch. > > The output is written to /etc/terminfo/ or $HOME/.terminfo/, > depending on the privileges of the user the tic command runs as. > The ncurses library searches for terminal definitions in several places, > including these two directories. Thanks for the suggestion, Mirko. I may incorporate this in a future edition of my web page. A source package modification to coreutils will still be necessary, though, so that dircolors recognizes the new terminal definition as one that supports color. The only exception would be if you were creating a new terminal definition for a terminal that does *not* support color. Actually, I think this is poor design. In my opinion, dircolors should make an ncurses call to determine if the terminal supports color, rather than using an independent internal database of terminals which support color. There's too much chance of these two independent databases getting out of sync, as we see has already happened with xterm-utf8. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/11359349.4274949.1413058531316.javamail.zim...@wowway.com
Re: question about systemd
On Sb, 11 oct 14, 12:40:58, Bob Holtzman wrote: > > I don't have a task or a mission here. I simply asked a question. And the answer is: dependencies don't start their existence by installing the depended-on package. If this is not what you meant by "entanglement" please clarify. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Newbie friendly security and firewall docs (cookbook?)
Hi: I might be able to help here as well. I have some teaching notes somewhere when I taught system security at my college. Peter On 09/10/14 05:03 PM, Lisi Reisz wrote: On Thursday 09 October 2014 21:59:12 Charlie wrote: On Thu, 09 Oct 2014 02:54:48 +0200 lee sent: I still have a very good tutorial that uses iptables and helps you to learn how to build a firewall. I've archived it for reference in 2003. I could send it to you by email if you like (760kB). I would be very interested in this as well Lee. May I add myself to the list? Thank you. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543992cc.6070...@rogers.com
Re: question about systemd
On Sat, 11 Oct 2014 20:06:14 +0200 Slavko wrote: > Ahoj, > > Dňa Sat, 11 Oct 2014 18:41:12 +0100 Brian > napísal: > > > And to illustrate how much work Debian maintainers put in to respond > > to users' concerns: > > > > root@gnome-jessie:~# apt-get install sysvinit-core systemd-shim > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > The following extra packages will be installed: > > cgmanager libcgmanager0 libnih-dbus1 libnih1 > > Suggested packages: > > pm-utils > > The following packages will be REMOVED: > > systemd-sysv > > The following NEW packages will be installed: > > cgmanager libcgmanager0 libnih-dbus1 libnih1 systemd-shim > > sysvinit-core 0 upgraded, 6 newly installed, 1 to remove and 0 not > > upgraded. Need to get 482 kB of archives. > > After this operation, 1,030 kB of additional disk space will be > > used. Do you want to continue? [Y/n] > > > > What more could a Debian user want? > > I don't know what other users want, but i tried it some days ago (when > the latest version of the systemd comes into testing) and i want e.g. > to be able to reboot, shutdown, suspend and hibernate the machine as > regular user from my XFCE session. That is all, what i want and when i > try it, i get message about insufficient permissions. From what I've heard on this list, Xfce has drunk the systemd koolaid. If that's true, screw em, they're not the only game in town. If nothing else, use Openbox with a no-brand panel, and that's kind of like Xfce. Oh, and make a few sudoers entries so you can reboot, shutdown, suspend and hibernate as a normal user. > > I ask here for help, but no one (i expect the response especially from > these who tells, that this ML is for support not for discussion) give > me the solution how to get the sufficient permissions back. I'd just work around their silly BS. sudoers plus shellscripts plus one of those multi-launchers to call those shellscripts should do that job. And maybe submit a bug report to Xfce telling them their new master killed features you use every day. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011161605.6254c...@mydesq2.domain.cxm
Re: question about systemd
On 11/10/14 20:00, Nate Bargmann wrote: This is the question I have, what are the stated boundaries of the systemd project? Have any boundaries/goals been stated in terms of when systemd will be feature complete? Didn't Mr. Poettering make it sufficiently clear in numerous speeches that the ultimate goal of the systemd people was to create an entirely new OS? Just listen to the first two minutes of the first youtube video you get when searching for his name: http://www.youtube.com/watch?v=LdRmnSHHVw4 Or is my English so bad that I misinterpret almost every sentence he says? Isn't it the main point of our criticism that we are losing the OS we originally chose when installing Debian, because some people are now gradually changing it to an entirely different OS that closely resembles MS Windows? p. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m1c5p2$f6d$1...@ger.gmane.org
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sat, 11 Oct 2014 21:21:14 +0300 Andrei POPESCU wrote: > On Sb, 11 oct 14, 13:40:08, Steve Litt wrote: > > > > sysvinit is an idea whose time has gone. sysvinit is a poor way to > > showcase the Unix Way. First of all, the whole idea of runlevels is > > bizarre, and adds a lot of complexity to init scripts. If you > > compare a daemontools /service/myserviced/run to an init script, > > you'll see an order of magnetude simplification, without > > sacrificing the flexibility of a shellscript. > > Why should I write a script? I'm not a programmer. Why should I configure and maintain a firewall? I'm not an admin. One's being a "programmer" is such an arbitrary division. OK, you're not the first guy I'd call if I wanted a device driver coded, but I'd have complete confidence in you to write a short shellscript. And, being able to write a short shellscript (which I'm sure you can do), would make you a much more able Linux administrator and user. > > [snip] > > > I *might* characterize the preceding as trying to reduce complexity > > for the dufus who can't even write a shellscript. However, the cost > > of this reduced complexity for the dufus is huge complexity within > > the program: complexity even smart people can't work around without > > some truly ridiculous kludges. > > I can write a (simple) shellscript, but I wouldn't dare write an > initscript or even a daemontools runscript. Daemontools runscripts are incredibly simple shellscripts, that I'm sure you could write no sweat except in very wierd edge cases. Here's my run script for my home-grown cron substitute: == #!/bin/sh ### DON'T START littcrond UNTIL THE NETWORK'S UP ### pingaddr=8.8.8.8 pingaddr=192.168.100.96 echo littcrond checking network 1>&2 while ! ping -q -c1 $pingaddr > /dev/null; do sleep 1 echo littcrond REchecking network 1>&2 done ### RUN THE DAEMON ### exec envuidgid slitt envdir ./env setuidgid slitt \ /d/at/python/littcron/littcron.py \ /d/at/python/littcron/crontab == The last three lines are really one line that wordwraps in email. If I hadn't checked for the network being up, this would have been a two line shellscript. I've known you (online) for several months, and although we sometimes disagree, I know you're pretty smart, so I'm positive you could have written this shellscript without breaking a sweat. > > > I have a theory on that. runit, s6, init-ng, etc never caught on > > because sysvinit was considered good enough, and it was easier for > > the average person to work around its rough edges rather than learn > > a new init system. > > I recently needed something to run imapfilter and restart it in case > it might exit, so I had a look at daemontools. I gave up quickly > after I realised the amount of scaffolding required just to get > daemontools itself running (additional top-level directories, are you > kidding?). > > With systemd (v215) I had to write this unit file: [clip Andre's easy description of daemonizing imapfilter with systemd] Yes, there's significant scaffolding, mostly revolving around installing daemontools. Also, Andre didn't bring this up, but it's implicit in his objection: Most daemontools documentation is terse and assumes a whole lot of Unix-smarts on the part of the reader, with few examples. That's why I wrote this document: http://www.troubleshooters.com/linux/djbdns/daemontools_intro.htm Armed with the preceding document, a person can learn daemontools in a day, and use it for the rest of his life. If you can run imapfilter in the foreground, it's trivial to have daemontools daemonize it for you. And you'll know *exactly* how it's going to work. The other benefit of daemontools is it works, every single time. It never misfires, it never behaves in ways that are unspecified or against specification, it keeps working for years, and a simple (as root) backup walks it from distro to distro. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011172828.4a603...@mydesq2.domain.cxm
Re: question about systemd
Reco wrote: Hi. On Sat, 11 Oct 2014 20:11:57 +0100 Brian wrote: On Sat 11 Oct 2014 at 13:00:12 -0500, Nate Bargmann wrote: I fear that we are living the axiom, "Those who do not understand UNIX are condemned to reinvent it, poorly." That is a misquote. Understandable when it is all over the web and comes up with a search engine, so don't worry about it. It should be "Those who do not understand systemd are condemned to reinvent it, poorly." You misquote it too. An original quote was: "Those who do not understand Solaris SMF are condemned to reinvent it, with systemd, poorly." I believe the original is "Those who don't know LISP are bound to reinvent it, poorly." Systemd, written in LISP - now that might be interesting! Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54399e15.8010...@meetinghouse.net
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
On Sat, 11 Oct 2014 23:20:34 +0400 Reco wrote: > Hi. > > On Sat, 11 Oct 2014 20:47:36 +0300 > Andrei POPESCU wrote: [huge snip] > > No, that was just for the "I'm sole user of this system, why would > > I need this logind stuff?" crowd. > > Thanks, I'm perfectly aware why I don't need logind - it does not > solve any of the problems I need to solve. Same for it's predecessor, > ConsoleKit. > If I ever need a computer with the multiple X servers running > simultaneously - I'll consider using logind. Am I missing something. If I needed multiple X servers, wouldn't I just CLI log into different users on Ctrl+Alt+F2 and Ctrl+Alt+F3, and run startx from each? SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011173500.03936...@mydesq2.domain.cxm
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi. On Sat, 11 Oct 2014 23:02:01 +0300 Andrei POPESCU wrote: > On Sb, 11 oct 14, 23:20:34, Reco wrote: > > On Sat, 11 Oct 2014 20:47:36 +0300 > > Andrei POPESCU wrote: > > > > > At least with systemd if you fix a bug it will benefit all daemons using > > > it. > > > > No, quite the contrary. By fixing such jack-of-all-trades > > libsystemd library you're risking to *break* some other daemons. > > But, pretending your point is valid, fixing /etc/init.d/skeleton grants > > the same benefits. > > Nope. The reason being? Code quality of systemd is not top-grade (to say lightly), and the project hardly reached its' maturity. It'll only get worse from here. And, I have to ask. Are you denying both of my statements, or the last one only? > > > This is the same reason we are using shared libraries and the Debian > > > Security Team is doing it's best to track code copies. > > > > Consider /etc/init.d/skeleton a library then. It's sources to > > any /etc/init.d script anyway. > > No, it doesn't. Again, simple 'no' is beautiful, but hardly contributes to the discussion. > > > True, but sysv-rc still can't deal with them correctly. > > > > It does not have to deal with the hardware, as it not its' job. > > It has to mount filesystems. No, it does not have to. In Debian, there's /etc/init.d/mountall.sh to do this job, in case initrd didn't care for it already. init(8) does not mount anything. And, to spice things up, [1]. Beautiful link telling everyone that it's not the init job to mount /usr as there's initrd for that. > > Ok. You have wired, that's one stanza in /etc/network/interfaces. Or > > one obscure systemd's unit, if you prefer *that*. > > You have wireless, and while it's possible to > > use /etc/network/interfaces for that too (I do, for example), Joe the > > Average User would probably use NetworkDestroyer (sorry, Manager), or > > wicd. Anyway, wireless requires usage of wpa_supplicant, which is not a > > part of systemd. Presumably one can use a systemd's unit for that too, > > but I've never tried it. > > A dongle for a mobile is probably a good old g_ether network interface > > aka usb0. It's complicated somewhat as one may need to use > > usb-modeswitch (not a part of systemd, btw), but it's nothing more > > complex than yet another stanza in /etc/network/interfaces. > > As for the IPv6 - unless you're turning your own PC into a router, > > configuring IPv6 is something that kernel does for you already without > > any intervention from the userspace (it's called a Router Advertisment). > > My point was that userspace has to react to changes in networking. The > following might also provide for an interested read: > http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Oh, you've meant *that* by complex. Ok, I misunderstood you. Along all presumably good things that page tells, there's these gems: This will ensure that all configured network devices are up and have an IP address assigned before boot continues. This service will time out after 90s. Enabling this service might considerably delay your boot even if the timeout is not reached. Both services are disabled by default. … If you are a developer, instead of wondering what to do about network.target, please just fix your program to be friendly to dynamically changing network configuration. That way you will make your users happy because things just start to work, and you will get fewer bug reports as your stuff is just rock solid. Please enlighten me what exactly is systemd-specific here. Basically they tell "yadda-yadda-yadda, fix your applications, and if you don't - we have this 90-second hack for you". > > You don't have to, in this specific case. NFS should be mounted long > > before any daemon starts, mpd included. Things can break, as your > > example show. > > A better example would be 'how I can ensure that mpd will > > stop if I unmount a NFS share?'. > > Still, I agree that's a valid point, *if* you disregard an existence > > of automount(5). Because, mounting NFS from an fstab is *so* AIX. > > Why should I need to install yet another daemon, with yet another > configuration file/syntax? Brilliant question. Certainly you've meant systemd, right? Just joking. Joke aside - because it's convenient to mount a filesystem once you really need it, and (which is much more important) - unmount it once it's not needed anymore. > > [3] tells us "systemd 30 and newer include systemd-logind. This is a > > tiny daemon that manages user logins and seats in various ways." > > I had an impression that an ssh login is an actual login. > > And, since you can easily start an X session over ssh - there's need to > > consider it a ssh login a seat too. > > Are you talking about X forwarding? Isn't the X session on the ssh > client side (a.k.a. the X server side)? X server on host A. ssh connection from host A to host B. X clients wrapped in X session on host B. Saves the trouble of using XDMCP. Call it the
Re: question about systemd
On Sat 11 Oct 2014 at 16:16:05 -0400, Steve Litt wrote: > From what I've heard on this list, Xfce has drunk the systemd koolaid. What have you heard? Have you a link on -user to give us so we can judge for ourselves? > If that's true, screw em, they're not the only game in town. If nothing Love the "If that's true.". You actually don't know, do you? You have nothing to back up what you say. I have Xfce on unstable without systemd. Do you have to make a great effort to post inaccurate and misleading information or does it come naturally? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/11102014220452.164da1ac4...@desktop.copernicus.demon.co.uk
Re: implicit linkage
On Sat, 11 Oct 2014 22:28:31 +0300 Andrei POPESCU wrote: > Really? How do you write an initscript that restarts your daemon > automatically in case it fails for some reason? > > Also, imapfilter doesn't write a pidfile at all, so I'd need to make > at least some modifications to the script. Does imapfilter run in the foreground, or does it have an option to run in the foreground? SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011174128.4afe4...@mydesq2.domain.cxm
Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)
Hi. On Sat, 11 Oct 2014 17:35:00 -0400 Steve Litt wrote: > On Sat, 11 Oct 2014 23:20:34 +0400 > Reco wrote: > > > Hi. > > > > On Sat, 11 Oct 2014 20:47:36 +0300 > > Andrei POPESCU wrote: > > [huge snip] > > > > No, that was just for the "I'm sole user of this system, why would > > > I need this logind stuff?" crowd. > > > > Thanks, I'm perfectly aware why I don't need logind - it does not > > solve any of the problems I need to solve. Same for it's predecessor, > > ConsoleKit. > > If I ever need a computer with the multiple X servers running > > simultaneously - I'll consider using logind. > > Am I missing something. If I needed multiple X servers, wouldn't I just > CLI log into different users on Ctrl+Alt+F2 and Ctrl+Alt+F3, and run > startx from each? That's one way of doing it, sure. An old way, and a convenient one, but it's somewhat cruel to expect from the average user these days. An alternative would be some kind of a Display Manager (even venerable xdm will suffice). But that's not the point. The point is the following scenario: 1) A single shared PC with 2 users just to keep it simple. 2) User Alice logs in and starts browsing the Internet and listening some music. 3) User Alice goes away, but keeps her session in place, locking the screen. 4) User Bob logs in another X session. 5) User Bob does not share Alices' music tastes, yet he's unable to shut off Alices' music as he's the different user. So, unless Bob has root password - he's doomed (pun intended) to listen the music he does not like. Presumably that scenario is something that logind has to overcome. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012014940.0e2fe89eba55854a664d1...@gmail.com
Re: Newbie friendly security and firewall docs (cookbook?)
Dear list contributors, On Sat, 11 Oct 2014 16:27:56 -0400 Peter Zoeller wrote: > Hi: > I might be able to help here as well. I have some teaching notes > somewhere when I taught system security at my college. > > Peter > On 09/10/14 05:03 PM, Lisi Reisz wrote: > > On Thursday 09 October 2014 21:59:12 Charlie wrote: > >> On Thu, 09 Oct 2014 02:54:48 +0200 lee sent: > >>> I still have a very good tutorial that uses iptables and helps you to > >>> learn how to build a firewall. I've archived it for reference in > >>> 2003. I could send it to you by email if you like (760kB). > >> I would be very interested in this as well Lee. > > May I add myself to the list? While I'm not Peter, there's classic treatise on the matter in comparison to which everything else does not seem to be worthy of your attention. THE 'Iptables Tutorial': http://rlworkman.net/howtos/iptables/iptables-tutorial.html Unless it's not there - you don't need it. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012015923.e788d98c9669bb19a40db...@gmail.com
Re: question about systemd
On Sat, 11 Oct 2014 20:03:18 +0100 Martin Read wrote: > On 11/10/14 19:00, Nate Bargmann wrote: > > This is the question I have, what are the stated boundaries of the > > systemd project? Have any boundaries/goals been stated in terms of > > when systemd will be feature complete? What is the stated > > compliance to POSIX (Google doesn't seem to provide me good > > results)? > > In respect of the first two questions: I am not aware of any such > firm statements having been made. > > In respect of your third question: Contrary to the implicit > expectation that seems to be attached to this question, POSIX.1-2008 > appears to have very little to say about how any of the things > systemd does are supposed to work. I think the source of most POSIX questions re systemd is the fact that Poettering has publically stated POSIX should be ignored under certain circumstances, and I mean a lot more circumstances than any Linux implementation currently ignores it. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011173951.50c60...@mydesq2.domain.cxm
Re: question about systemd
On Sat, 11 Oct 2014 17:16:05 -0400 Miles Fidelman wrote: > Reco wrote: > > Hi. > > > > On Sat, 11 Oct 2014 20:11:57 +0100 > > Brian wrote: > > > >> On Sat 11 Oct 2014 at 13:00:12 -0500, Nate Bargmann wrote: > >> > >>> I fear that we are living the axiom, "Those who do not understand UNIX > >>> are condemned to reinvent it, poorly." > >> That is a misquote. Understandable when it is all over the web and comes > >> up with a search engine, so don't worry about it. It should be > >> > >>"Those who do not understand systemd are condemned to reinvent > >> it, poorly." > > You misquote it too. An original quote was: > > > > "Those who do not understand Solaris SMF are condemned to reinvent it, > > with systemd, poorly." > > > > I believe the original is "Those who don't know LISP are bound to > reinvent it, poorly." > > Systemd, written in LISP - now that might be interesting! One must be *very* careful to wish for - [1]. OK, that's not pure LISP, it's Scheme :) [1] http://www.gnu.org/software/guix/ Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012015334.61797c67846332b28319a...@gmail.com
In Poettering's own words: was question about systemd
On Sat, 11 Oct 2014 22:58:18 +0200 Peter Nieman wrote: > Didn't Mr. Poettering make it sufficiently clear in numerous speeches > that the ultimate goal of the systemd people was to create an > entirely new OS? Just listen to the first two minutes of the first > youtube video you get when searching for his name: > http://www.youtube.com/watch?v=LdRmnSHHVw4 Breathtaking! At timestamp 0:51 he says that systemd is now more than just an init system, it's a set of building blocks to build an operating system. Nowhere does he say that if you accept any of those tools, you need to throw away several tools you've been using, or that if you use certain systemd tools, you need to install many of them. He glosses over the "in for a penny, in for a pound" nature of systemd. It's not a set of a-la-carte building blocks, it's a huge meal. At timestamp 1:35, he says that systemd "feels more like a real operating system". Amazing: here I thought that I *had* been using a real operating system since I installed Linux in 1998. We should rejoice that, after almost a couple decades, Debian is now, finally, a *real* operating system! At 2:20, he states that "we believed the operating system design isn't the right design to have." Then why the hell are they still calling what they're moving to Linux? And what, we've been using the wrong operating system all these years? At 2:45 he says that you tell systemd what the dependencies of things are, and systemd figures out at boot time what to do. Hey, couldn't that be done with a make file, with a whole less code and fanfare? LOL, make boot. 7:19 he says that Debian's in the process of deciding whether Debian should switch to it. And at 8:06 he said Cannonical really hates systemd. So when the CTTE chose systemd, that's the only thing that brought Ubuntu on board, and all resistance was gone. Nice! Thanks guys. It appears that because of that vote, the Linux of the future will be a totally different operating system, and I'll have *very* limited choices if I happen to like the real Linux, instead of the Red Hat fork. How anybody familiar with this interview could have included systemd as an option, let alone the default, is beyond my comprehension. Several months ago somebody referred to systemd as Embrace, Extend, Extinquish, and at the time I thought he was over the top. But that's basically exactly what Poettering says in this 9:31 interview. Everybody should view this video! SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011182053.1dab4...@mydesq2.domain.cxm
Re: implicit linkage
On 10/11/2014 05:28 PM, Steve Litt wrote: > On Sat, 11 Oct 2014 21:21:14 +0300 > Andrei POPESCU wrote: > >> On Sb, 11 oct 14, 13:40:08, Steve Litt wrote: >>> >>> sysvinit is an idea whose time has gone. sysvinit is a poor way to >>> showcase the Unix Way. First of all, the whole idea of runlevels is >>> bizarre, and adds a lot of complexity to init scripts. If you >>> compare a daemontools /service/myserviced/run to an init script, >>> you'll see an order of magnetude simplification, without >>> sacrificing the flexibility of a shellscript. >> >> Why should I write a script? I'm not a programmer. > > Why should I configure and maintain a firewall? I'm not an admin. > > One's being a "programmer" is such an arbitrary division. OK, you're > not the first guy I'd call if I wanted a device driver coded, but I'd > have complete confidence in you to write a short shellscript. And, > being able to write a short shellscript (which I'm sure you can do), > would make you a much more able Linux administrator and user. > >> >> [snip] >> >>> I *might* characterize the preceding as trying to reduce complexity >>> for the dufus who can't even write a shellscript. However, the cost >>> of this reduced complexity for the dufus is huge complexity within >>> the program: complexity even smart people can't work around without >>> some truly ridiculous kludges. >> >> I can write a (simple) shellscript, but I wouldn't dare write an >> initscript or even a daemontools runscript. > > Daemontools runscripts are incredibly simple shellscripts, that I'm > sure you could write no sweat except in very wierd edge cases. Here's > my run script for my home-grown cron substitute: > > == > #!/bin/sh > > ### DON'T START littcrond UNTIL THE NETWORK'S UP ### > pingaddr=8.8.8.8 > pingaddr=192.168.100.96 > echo littcrond checking network 1>&2 > while ! ping -q -c1 $pingaddr > /dev/null; do >sleep 1 >echo littcrond REchecking network 1>&2 > done > > ### RUN THE DAEMON ### > exec envuidgid slitt envdir ./env setuidgid slitt \ >/d/at/python/littcron/littcron.py \ >/d/at/python/littcron/crontab > == > > The last three lines are really one line that wordwraps in email. If I > hadn't checked for the network being up, this would have been a two > line shellscript. I've known you (online) for several months, and > although we sometimes disagree, I know you're pretty smart, so I'm > positive you could have written this shellscript without breaking a > sweat. > > /snip/ I've been using Linux seriously for about five years, altho I diddled around with it a bit earlier. About the time I started seriously using it, I took a course in Linux at the local community college, of which perhaps a third was devoted to scripting. Quite some time earlier, I had taken a course in Pascal, which I did very well in, and I actually wrote some useful code in that language for my job as an engineer. Prior to that, I used and wrote a lot of stuff in BASIC. Getting back to my Linux class, I received a B+. I don't know how much code I could have actually written when class was over, since one needs to know a lot more about system commands. At any rate, it's been about five years, and I could not now write the script you use to illustrate this message, and I'm not really sure I can read it! BASH scripts are written in perfectly logical code, quite similar, in fact, to Pascal. The problem is that they don't have the advantage of normal language; they rely on all sorts of abbreviations instead of the English words that more popular programming languages like Pascal, C, Python, and BASIC use. It's been probably 25 years since I wrote anything in Pascal or BASIC, but with about 30 minutes of reference-book research, I think I could go back and do it now. I can't imagine that to be true with BASH scripting. Just call me dufus. --doug -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5439b7af.4000...@optonline.net
Fwd: Loading OS into software model of SPARC(without BIOS and boot loader)
-- Forwarded message -- From: Renju Boben Date: Mon, Sep 29, 2014 at 3:54 AM Subject: Loading OS into software model of SPARC(without BIOS and boot loader) To: sparcli...@vger.rutgers.edu Hi, I have the software model of a SPARC v8 processor and its Memory management unit. The model accepts input (instructions) in the form . I am trying to load stripped down Linux 3.1.4 into it (without BIOS and boot loader). I have the kernel in the required format. But i don,t know from which address to start executing. Also, what should be the condition of the registers when the OS is about to load. I have read that in x86 architecture after 640KB there are special jump instructions (because original 8086 only had 640 KB of memory). Are there any similar jumps in SPARC. if so how does if affect loading OS. Has this jumping any dependence on Boot loader Regards, Renju Boben
Re: question about systemd
Reco writes: > One must be *very* careful to wish for - [1]. OK, that's not pure LISP, > it's Scheme :) > [1] http://www.gnu.org/software/guix/ http://en.wikipedia.org/wiki/Lisp_machine -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oati9o5p@thumper.dhh.gt.org
Re: In Poettering's own words: was question about systemd
Testing, here. Just want to check whether I get filtered out from here, as well. (Two responses to a thread that invites discussion of the /usr merge have not made it to the list yet.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43inwe0hv5puqovuakwe0sxtks0qm-xb78k_hlqewwyp...@mail.gmail.com
Re: segfaults and error 4 in ld-2.13.so with soffice.bin and kate
On 10/07/2014 03:00 PM, Gary Roach wrote: After cloning my bad drive to a new one and installing the new drive (see previous messages titled excessive CPU usage) i am left with the following problem: Kate and libreoffice.writer refuse to open and give the errors soffice.bin[10369]: segfault at 7ffe25921b1c ip 7ffd559f97c3 sp 7fff317bc4a0 error 4 in ld-2.13.so[7ffd559f+2] and kate[8636]: segfault at 7fa4e4a5cb3f ip 7fa4a700eadd sp 7fff31fbd630 error 4 in ld-2.13.so[7fa4a7005000+2]respectively. These fault messages were found in th kern.log file Any attempt to start kate produces the message and drops back to the prompt. Libreoffice will start and works for everything except writer. Writer will start but errors out when an attempt is made to open an odt file. Doc files open OK. I have tried every program that is installed on my system. All others work fine. System information: OS Debian Linux amd64 Wheezy Intel i5-750 processor with Intel mother board I've searched the net and this list hand have not found any useful information. Any help will be sincerely appreciated. Gary R. I found several internet references to memory errors as a cause for segfault errors and tried to run both memtest86 and memtes86+. Both programs gave the same error message. - error:too small lower memory (0x99100 > 0x8f000). There are indications that this is a bug in the memtest programs and not a system problem. What is true and what should I do about it. The original problem is still hear and I have no idea how to fix it. Please help!!! Gary R. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5439d783.8040...@verizon.net
Re: segfaults and error 4 in ld-2.13.so with soffice.bin and kate
On Tue, 07 Oct 2014, Gary Roach wrote: > After cloning my bad drive to a new one and installing the new drive > (see previous messages titled excessive CPU usage) i am left with the > following problem: > > Kate and libreoffice.writer refuse to open and give the errors I would reinstall libreoffice, kate, and all of their dependencies before going too far into this. It's quite possibly that your bad drive had a bad sector or similar in one or more of these programs... especially since you didn't experience these segfaults before, and no one else has either. Something like: aptitude reinstall '?reverse-Depends(libreoffice)~i'; aptitude reinstall '?reverse-Depends(kate)~i'; will do that for you. If they still occur, enable coredumps, and get a backtrace of the coredump using gdb or similar. [You'll also want to install all of the -dbg packages you can for the libraries referenced in the backtrace.] -- Don Armstrong http://www.donarmstrong.com One day I put instant coffee in my microwave oven and almost went back in time. -- Steven Wright -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012012820.gq23...@teltox.donarmstrong.com
Re: segfaults and error 4 in ld-2.13.so with soffice.bin and kate
Am 12.10.2014 um 03:28 schrieb Don Armstrong: > On Tue, 07 Oct 2014, Gary Roach wrote: >> After cloning my bad drive to a new one and installing the new drive >> (see previous messages titled excessive CPU usage) i am left with the >> following problem: >> >> Kate and libreoffice.writer refuse to open and give the errors > > I would reinstall libreoffice, kate, and all of their dependencies > before going too far into this. > > It's quite possibly that your bad drive had a bad sector or similar in > one or more of these programs... especially since you didn't experience > these segfaults before, and no one else has either. Running a debsums check might be a good idea as well to find possibly corrupted files. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bash usage: was implicit linkage
On Sat, 11 Oct 2014 19:05:19 -0400 Doug wrote: > On 10/11/2014 05:28 PM, Steve Litt wrote: > > On Sat, 11 Oct 2014 21:21:14 +0300 > > Daemontools runscripts are incredibly simple shellscripts, that I'm > > sure you could write no sweat except in very wierd edge cases. > > Here's my run script for my home-grown cron substitute: > > > > == > > #!/bin/sh > > > > ### DON'T START littcrond UNTIL THE NETWORK'S UP ### > > pingaddr=8.8.8.8 > > pingaddr=192.168.100.96 > > echo littcrond checking network 1>&2 > > while ! ping -q -c1 $pingaddr > /dev/null; do > >sleep 1 > >echo littcrond REchecking network 1>&2 > > done > > > > ### RUN THE DAEMON ### > > exec envuidgid slitt envdir ./env setuidgid slitt \ > >/d/at/python/littcron/littcron.py \ > >/d/at/python/littcron/crontab > > == > > > > The last three lines are really one line that wordwraps in email. > > If I hadn't checked for the network being up, this would have been > > a two line shellscript. I've known you (online) for several months, > > and although we sometimes disagree, I know you're pretty smart, so > > I'm positive you could have written this shellscript without > > breaking a sweat. > > > > > /snip/ > > I've been using Linux seriously for about five years, altho I diddled > around with it a bit earlier. About the time I started seriously using > it, I took a course in Linux at the local community college, of which > perhaps a third was devoted to scripting. Quite some time earlier, I > had taken a course in Pascal, which I did very well in, and I actually > wrote some useful code in that language for my job as an engineer. > Prior to that, I used and wrote a lot of stuff in BASIC. > Getting back to my Linux class, I received a B+. I don't know how much > code I could have actually written when class was over, since one > needs to know a lot more about system commands. At any rate, it's > been about five years, and I could not now write the script you use > to illustrate this message, and I'm not really sure I can read it! > > BASH scripts are written in perfectly logical code, quite similar, in > fact, to Pascal. The problem is that they don't have the advantage > of normal language; they rely on all sorts of abbreviations instead > of the English words that more popular programming languages like > Pascal, C, Python, and BASIC use. It's been probably 25 years > since I wrote anything in Pascal or BASIC, but with about 30 minutes > of reference-book research, I think I could go back and do it now. > I can't imagine that to be true with BASH scripting. > > Just call me dufus. > > --doug Hi Doug, You're absolutely right. From my viewpoint, shellscripts were never intended to be big, huge programs. To me, they just glue together commands, and have a few rudimentary branching and looping constructs. Their loops are incredibly slow, you'd *never* do an inner loop in Bash. To me, if something involves you doing your own logic rather than calling other executables to do it, then Python, C, or some other "real" language is the way to do it. So yes, sysvinit startup scripts are on the far edge of what Bash should be used for. I'd say most daemontools run scripts are under 20 lines of code, so you'll be able to re-figure them, in a few minutes, six months from now. Now that I've said that, you can accomplish some pretty incredible things by gluing a few commands together. I wrote the better half of a http log evaluation program using a shellscript gluing together grep, cut, and awk, and piped the remainder (which was a much smaller data set than what went in) to a Python program or something like that. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011214049.0a4dd...@mydesq2.domain.cxm
Re: question about systemd
On Sat, Oct 11, 2014 at 09:23:08PM +0300, Andrei POPESCU wrote: > On Sb, 11 oct 14, 13:01:38, James Ensor wrote: > > > > And, just for the record, I started this exercise just because I was > > curious what would happen if I removed systemd. I don't claim to > > understand all the complexities of init systems (as you have been able > > to tell). Honestly my system seemed to be working just fine with > > systemd, and it's working fine without it. I don't really have an > > opinion about it. Many of the opinions I have seen expressed in this > > thread seem to me to be based not on any facts or knowledge, but more > > on prejudice. > > Agreed. Otherwise known as FUD. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012013624.GB30520@tal
Re: question about systemd
John Hasler wrote: Reco writes: One must be *very* careful to wish for - [1]. OK, that's not pure LISP, it's Scheme :) [1] http://www.gnu.org/software/guix/ http://en.wikipedia.org/wiki/Lisp_machine And a beautiful machine it was, too. Miles -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5439ddaf.8050...@meetinghouse.net
Re: Bash usage: was implicit linkage
On Sat, Oct 11, 2014 at 09:40:49PM -0400, Steve Litt wrote: > > Now that I've said that, you can accomplish some pretty incredible > things by gluing a few commands together. I wrote the better half of a > http log evaluation program using a shellscript gluing together grep, > cut, and awk, and piped the remainder (which was a much smaller data > set than what went in) to a Python program or something like that. Don't try and replicate Perl, just use it. :) -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141012022536.GB32189@tal
Re: question about systemd
On 10/10/2014 8:44 AM, James Ensor wrote: > But, to get more to the point of my original question, there has been > so much discussion about systemd here, but as far as I can tell very > little of this discussion has been of practical use for a debian-user. Are you crazy, people are having problems -- left, right and center! How do DDs think it's going to get better when systemd becomes the tyranny of default? This is madness. More experiences sysadmins can deal with this more easily than newer users whom will come along, be baffled and go away -- unless they are extremely lucky not to have had any issues out of the box. For all those sysadmins that need to keep production servers in full and normal operation, systemd will be a nightmarre. It sure might be as simple as uninstall systemd after making sure sysvinit pieces are there, but that will be a horrible kludge. Please DDs get that GR happening before Debian is history over this crazy change. A. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5439e674.9010...@affinityvision.com.au
Re: question about systemd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/10/2014 2:01 AM, James Ensor wrote: > The point of this thread was to demonstrate that you *do* still have a > choice. It's relatively simple to remove systemd from your Debian > installation if you choose to. In the short term, sure, but in the long term, we are so screwed if this change remains. A. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlQ56kAACgkQqBZry7fv4vsjcwD9H6sVO8+9/0ClMaiUV6RxzMnd MgNPBroUeWEKsoIKAosBAJi5b85GDx083TuwYkxSI06geORoz6v0NKpINYD40MWW =8Rvm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5439ea42.8090...@affinityvision.com.au
Re: Bash usage: was implicit linkage
Hi Steve: I agree that shell scripts are simplistic and not meant for fancy programs although it could be done, just not productive. But the nice thing is shell scripting is simplistic easy to learn and understand. Sure beats the days when I wrote code in Assembler, Cobol, Fortran, PL1, RPG, Easytrieve, Focus. Those days are gone with the likes of Perl, Pascal, C++, etc. Peter On 11/10/14 09:40 PM, Steve Litt wrote: On Sat, 11 Oct 2014 19:05:19 -0400 Doug wrote: On 10/11/2014 05:28 PM, Steve Litt wrote: On Sat, 11 Oct 2014 21:21:14 +0300 Daemontools runscripts are incredibly simple shellscripts, that I'm sure you could write no sweat except in very wierd edge cases. Here's my run script for my home-grown cron substitute: == #!/bin/sh ### DON'T START littcrond UNTIL THE NETWORK'S UP ### pingaddr=8.8.8.8 pingaddr=192.168.100.96 echo littcrond checking network 1>&2 while ! ping -q -c1 $pingaddr > /dev/null; do sleep 1 echo littcrond REchecking network 1>&2 done ### RUN THE DAEMON ### exec envuidgid slitt envdir ./env setuidgid slitt \ /d/at/python/littcron/littcron.py \ /d/at/python/littcron/crontab == The last three lines are really one line that wordwraps in email. If I hadn't checked for the network being up, this would have been a two line shellscript. I've known you (online) for several months, and although we sometimes disagree, I know you're pretty smart, so I'm positive you could have written this shellscript without breaking a sweat. /snip/ I've been using Linux seriously for about five years, altho I diddled around with it a bit earlier. About the time I started seriously using it, I took a course in Linux at the local community college, of which perhaps a third was devoted to scripting. Quite some time earlier, I had taken a course in Pascal, which I did very well in, and I actually wrote some useful code in that language for my job as an engineer. Prior to that, I used and wrote a lot of stuff in BASIC. Getting back to my Linux class, I received a B+. I don't know how much code I could have actually written when class was over, since one needs to know a lot more about system commands. At any rate, it's been about five years, and I could not now write the script you use to illustrate this message, and I'm not really sure I can read it! BASH scripts are written in perfectly logical code, quite similar, in fact, to Pascal. The problem is that they don't have the advantage of normal language; they rely on all sorts of abbreviations instead of the English words that more popular programming languages like Pascal, C, Python, and BASIC use. It's been probably 25 years since I wrote anything in Pascal or BASIC, but with about 30 minutes of reference-book research, I think I could go back and do it now. I can't imagine that to be true with BASH scripting. Just call me dufus. --doug Hi Doug, You're absolutely right. From my viewpoint, shellscripts were never intended to be big, huge programs. To me, they just glue together commands, and have a few rudimentary branching and looping constructs. Their loops are incredibly slow, you'd *never* do an inner loop in Bash. To me, if something involves you doing your own logic rather than calling other executables to do it, then Python, C, or some other "real" language is the way to do it. So yes, sysvinit startup scripts are on the far edge of what Bash should be used for. I'd say most daemontools run scripts are under 20 lines of code, so you'll be able to re-figure them, in a few minutes, six months from now. Now that I've said that, you can accomplish some pretty incredible things by gluing a few commands together. I wrote the better half of a http log evaluation program using a shellscript gluing together grep, cut, and awk, and piped the remainder (which was a much smaller data set than what went in) to a Python program or something like that. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5439f183.9070...@rogers.com
Re: Using device UUSBs with cryptsetup to open already encrypted USB sticks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ken Heard wrote: > The command syntax for opening such a device is > > sudo cryptsetup luksOpen > > As I understand the syntax, the device designation can be /dev/sd?? > where the first question mark is the third letter of the device selected > by the OS, and the second question mark is the partition number. Since > device designation in this way is not constant I would like to use the > UUID of the device instead of having to check beforehand which sd > desognation the OS chose when each such stick is attached to the computer. > > Running sudo blkid -L I found the UUIDs for each stick which are quite > long, e.g., UUID="65e7697c-d5fa-4e16-84e9-c45d2f81dd69". I assume I can > somehow use such a UUID to indicate the device instead /dev/sd??, but I > cannot figure out how. The cryptsetup man page does not say how, nor > could I find out how by googling. > > If I knew how I could create individual script files to open and close > each stick. I would be using the bash shell for such scripts. (The > script would also include the mount/unmount command by using the > - UUID assigned to each stick after access to it is opened.) > > I would consequently appreciate it if someone could tell me how. After three hours of searching I finally found the answer to my own question: sudo cryptsetup luksOpen /dev/disk/by-uuid/65e7697c-d5fa-4e16-84e9-c45d2f81dd69 fdc (All on one line with a space between the luksOpen and the /dev/ ...) Regards, Ken -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlQ58ZYACgkQlNlJzOkJmTfLKQCdFqOA2yAxNkBtKNkKo9cmuVXn UxMAnj9pb7k01j2eW64qPntOnSZXTl8Y =xDYw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5439f196.3060...@teksavvy.com
Re: question about systemd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/10/2014 4:01 AM, James Ensor wrote: > What I was trying to say here is that people seem to want to debate > the philosophy/quality/whatever about systemd, and have used this to > come to wrong conclusions about the practical aspect of using an > alternate init system. That's just the nub of it, it /started/ as an init replacement and it has grown well beyond that [already] and is planned to grow much further beyond in order to make a *real operating system* -- watch the video from LCA conf from Perth... A. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlQ584kACgkQqBZry7fv4vvmpwD7BYLJzaQAe+/BS1N59oIDPsB+ Z1o1zRNutNohGgRHjS0BAKHexPn16yFPSFIzw3fNeVWwhpVG00WKq3BNZlHXqTA6 =wCFC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5439f38c.7030...@affinityvision.com.au
Re: question about systemd
On 10/11/2014 12:20 PM, Brian wrote: > On Sat 11 Oct 2014 at 12:49:15 -0400, Steve Litt wrote: > >> On Sat, 11 Oct 2014 13:53:20 +0300 >> Andrei POPESCU wrote: >> >>> You might want to check your facts: >>> >>> Linus Torvalds "only" created the Linux kernel, which is notoriously >>> monolithic[1]. >>> >>> [1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate >> >> This is very true, but the kernel knows its boundaries, and doesn't try >> to conquor all sorts of other, non-related, subsystems. > > What does that mean? It sounds deep but plumbing the depths of its > shallowness is a task for someone with more time than the universe has > got. > > It's pretty simple. The kernel has actual, literal boundaries, which it enforces. The part of the system you use is outside those boundaries, with certain mechanisms for passing data between user-space and kernel-space. If you took time away from insulting people on mailing lists to crack a book once in a while, you might know that. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m1d0j5$kst$1...@news.albasani.net
Re: question about systemd
On 10/10/2014 01:10 PM, James Ensor wrote:
> On Fri, Oct 10, 2014 at 3:27 PM, Bob Holtzman wrote:
>>
>> All well and good but what happens when sysv* get purged from the repos?
>>
>
> When is this going to happen?
>
>
I'm not aware of any intention to purge sysvinit-core from jessie or
sid. The old ("transitional") sysvinit package will eventually go away,
because sysvinit-core replaces it.
Even if sysvinit-core went away tomorrow, we'd not be stuck with only
systemd: openrc, runit, and even upstart are all still in the repos and
available for use.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m1d18j$8fk$1...@news.albasani.net
