[gentoo-user] [OT] easy to use proxy server
Hi, Please, could someone suggest easy to use proxy server which supports SSL? Thanks Pat Freehosting PIPNI - http://www.pipni.cz/
Re: [gentoo-user] [OT] easy to use proxy server
On 17 Feb 2014 16:15, pat p...@xvalheru.org wrote: Hi, Please, could someone suggest easy to use proxy server which supports SSL? Thanks Pat Freehosting PIPNI - http://www.pipni.cz/ Forward - squid, apache. Reverse - squid, apache, nginx
Re: [gentoo-user] [OT] easy to use proxy server
On Feb 17, 2014 11:46 AM, pat p...@xvalheru.org wrote: Hi, Please, could someone suggest easy to use proxy server which supports SSL? Thanks Pat Freehosting PIPNI - http://www.pipni.cz/ Have a look at squid (http://wiki.squid-cache.org/Features/HTTPS). As far as I remember it was just emerge -av squid, start the service and configure your browser to use the proxy on your server port 3128.
Re: [gentoo-user] [OT] easy to use proxy server
On Monday 17 Feb 2014 10:44:36 pat wrote: Hi, Please, could someone suggest easy to use proxy server which supports SSL? Thanks Pat There are many options depending on your requirements. You can use apache, or nginx, or net-proxy/tinyproxy, or even net-misc/proxytunnel. You can even use socat, stunnel and a combination of various tools for this purpose. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Thanks to all who chimed in... On 2014-02-16 3:27 PM, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote: [snip] You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. I had read that blog entry before. Is full of errors, like believing that everything that systemd does is inside PID 1. Maybe it is 'full of errors', but is the primary point true? There is actually little code inside PID 1; The quoted text said nothing about this, so please stay on point. As to the point raised: Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. So my main concern is - will it still be possible - *and* easy - in a year? Three years? Five? If the answer to *any* of those is no, then I think the best solution - for gentoo at least - is to make whether or not systemd is to be used more like a *profile* choice - a decision that you can make at install time, similar to choosing between hardened or not (not easy/simple to switch to/from after a system is up and running). In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, having it be a choice made by selecting a corresponding *profile* is the *ideal* solution - at least for gentoo. At least this way everything could be documented, and switching between a systemd and non-systemd profile can be supported for as long as possible, understanding that at some point in time it may have to become an install time choice - kind of like choosing between hardened or not is mostly an install time choice now.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 02/17/2014 06:17 AM, Tanstaafl wrote: Thanks to all who chimed in... On 2014-02-16 3:27 PM, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote: [snip] You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. I had read that blog entry before. Is full of errors, like believing that everything that systemd does is inside PID 1. Maybe it is 'full of errors', but is the primary point true? There is actually little code inside PID 1; The quoted text said nothing about this, so please stay on point. As to the point raised: Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. So my main concern is - will it still be possible - *and* easy - in a year? Three years? Five? If the answer to *any* of those is no, then I think the best solution - for gentoo at least - is to make whether or not systemd is to be used more like a *profile* choice - a decision that you can make at install time, similar to choosing between hardened or not (not easy/simple to switch to/from after a system is up and running). In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, having it be a choice made by selecting a corresponding *profile* is the *ideal* solution - at least for gentoo. At least this way everything could be documented, and switching between a systemd and non-systemd profile can be supported for as long as possible, understanding that at some point in time it may have to become an install time choice - kind of like choosing between hardened or not is mostly an install time choice now. That's actually a really smart idea. It would allow for the integration that systemd-fans desire and still respect the choice of people that don't want systemd on their systems. Combined with USE flags and the PORTDIR_MASK variable (iirc), it should create a best of both worlds situation for Gentoo and a decision wouldn't need to be made. Despite my distaste for systemd, I think this is a great middle ground that everyone could, with some considerations or compromises, agree to.
Re: [gentoo-user] JDK 7 on server
On Monday 17 February 2014 04:12 AM, Edward M wrote: On Sun, 16 Feb 2014 14:14:24 +0530 Nilesh Govindrajan m...@nileshgr.com wrote: rvices to customers, so compatibility is definitely a concern. I'm not exactly sure what the differences are between Oracle JDK OpenJDK; the differences I found so far on Google are old and make sense only for Java 6. Hello, To my understanding, Oracle JDK binary is created from the source code released from the OpenJDK project with some Oracle's own propriety code. The other difference is Oracle's JDK binary is released under Oracle Technology Network Developer License Terms for JAVA EE SDK,JDK where as OpenJDK code is under GPL + linking exceptions. More info at: https://blogs.oracle.com/henrik/entry/java_7_questions_answers Best regards ED So it would be correct to say that for Java EE applications, icedtea would be enough? As per the link you gave me, it says some graphical components fonts are extra, none of which are used in case of web applications.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 17/02/2014 14:17, Tanstaafl wrote: In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, having it be a choice made by selecting a corresponding *profile* is the *ideal* solution - at least for gentoo. At least this way everything could be documented, and switching between a systemd and non-systemd profile can be supported for as long as possible, understanding that at some point in time it may have to become an install time choice - kind of like choosing between hardened or not is mostly an install time choice now. To me, this is as close to ideal as it can get. As I said in my opening post, I do not suffer from the problem RedHat is solving - my machines seldom reboot quicker than every 10 days (including laptops) and OpenRC gets me to a useable prompt faster than the BIOS takes to do it's thing :-) A profile-like solution would suit me perfectly, something I can use or not as I see fit and the choice made at install time. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon alan.mckin...@gmail.com wrote: ... Whatever problems Red Hat are trying to solve in the Red Hat space are problems that do not affect me, so I do not need Red Hat's solution. As for Gnome, I have yet to see a valid reason why Gnome *must* use systemd; that is simply not true at all. I thought this all boiled down to trying to login to GDM using accessibility functions and a bluetooth hearing aid (or bluetooth keyboard, for that matter). Stroller.
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 07:22:17 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: How long has it been since Debian decided to go with systemd? Like, three? So, up until three days ago I would have disagreed since despite original upstream ditching ConsoleKit, it was still being maintained by Debian and Gentoo maintainers (me) and last release, 0.4.6, was in fact a result of that. And Debian hopefully will keep helping with any maintenance needed on it. They haven't decided to stop support of everything but systemd; they've only decided systemd will be the default.
RE: [gentoo-user] JDK 7 on server
Sorry for top post using my phone Ice tea is Java se. Glass server uses Java EE because EE has added API and Runtime to build enterprise secure apps. sorry the link did not help. Sent from my Windows Phone From: Nilesh Govindrajanmailto:m...@nileshgr.com Sent: 2/17/2014 6:07 AM To: gentoo-user@lists.gentoo.orgmailto:gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] JDK 7 on server On Monday 17 February 2014 04:12 AM, Edward M wrote: On Sun, 16 Feb 2014 14:14:24 +0530 Nilesh Govindrajan m...@nileshgr.com wrote: rvices to customers, so compatibility is definitely a concern. I'm not exactly sure what the differences are between Oracle JDK OpenJDK; the differences I found so far on Google are old and make sense only for Java 6. Hello, To my understanding, Oracle JDK binary is created from the source code released from the OpenJDK project with some Oracle's own propriety code. The other difference is Oracle's JDK binary is released under Oracle Technology Network Developer License Terms for JAVA EE SDK,JDK where as OpenJDK code is under GPL + linking exceptions. More info at: https://blogs.oracle.com/henrik/entry/java_7_questions_answers Best regards ED So it would be correct to say that for Java EE applications, icedtea would be enough? As per the link you gave me, it says some graphical components fonts are extra, none of which are used in case of web applications.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl tansta...@libertytrek.org wrote: [snip] Maybe it is 'full of errors', but is the primary point true? False implies whatever you want it to imply. You can't prove anything if your assumptions are incorrect. There is actually little code inside PID 1; The quoted text said nothing about this, so please stay on point. I was answering to someone else. As to the point raised: Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. I am not. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? I've never said it was easy. I said it could be done by someone willing and able. I repeated that like five times I think. I said it was done before; I never said it was easy. But it can be done, and that's a indisputable fact. It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. So my main concern is - will it still be possible - *and* easy - in a year? Three years? Five? If the answer to *any* of those is no, then I think the best solution - for gentoo at least - is to make whether or not systemd is to be used more like a *profile* choice - a decision that you can make at install time, similar to choosing between hardened or not (not easy/simple to switch to/from after a system is up and running). That's how it works right now, because Gentoo developers *did* the work. And the whole point of my willing and able mantra is to see if someone here steps up into the plate. It's *really* easy to say oh, systemd should be provided by a profile so the user is free to CHOICE if she wants to use it or not, but *someone* has to write the necessary support so that the profile actually exists. You want to be sure your choice is not taken away from you? Join Gentoo and help to make that choice possible. Don't expect that someone will do it for you. There is a lengthy discussion in gentoo-dev about the problem with understaffed arch teams. It's worth a reading, but the general consensus is that the minor archs cannot be kept in stable if there are not enough developers for said arch to do the testing. It sucks? Of course it sucks; but there is no magical fairy that automatically will keep working all the ebuilds for all the archs in Gentoo. SOMEONE has to do the testing, someone has to triage bugs, someone has to *fix* them. If there is no one, then the arch cannot be kept in stable. And that's a hard cold fact. If *all* the Gentoo developers switched to systemd (highly unlikely), then how could they support a separated profile for systemd? They won't, and your choice will then be taken away. If the Gentoo developers decide that having systemd in a separated profile is too much work (likely, even now), then what? More whining from users because they took away their choice? They could whine all they want, but if nobody steps up to the plate to do the actual work, nobody (necessarily) will do it for them. In fact, it seems to me that, since (from what I've read) the
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs in the critical system components are critical to the whole system. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. That's why critical components should be as simple and clean as possible. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. And all that science was ignored during systemd architecture process if there was any at all. Best regards, Andrew Savchenko pgpPqKWNVnvHI.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote: It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. And here we have a small problem: for modules to be replaceable the core system should be designed to support replaceable modules, but systemd is not. The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. Just imagine that one have PCI-E bus and this bug is being replaced with some other PC-systemd bus, where one have to interface each component differently. And if one removes e.g. audio card some other seemingly independent component e.g. network controller becomes broken. That is the nature of systemd and that is many people dislike this technology. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. The most sane and fair solution was already proposed: create a systemd profile for those who need it. I personally highly dislike systemd technology, but I respect the right of other to shoot them in the leg (or head) as much as they want to. This is Gentoo: a universal constructor providing people means to build any system in any shape they need. Unfortunately chances are that in future some software may become unusable or unsupported outside of systemd profile. But patches may be created and other profiles will continue to live the same way hardened exists now and will continue to exist later. BTW it was shown at the recent LVEE Winter 2014 conference that GDM can be easily freed from systemd and OpenBSD guys have an interesting idea for faking systemd presence for applications requesting one mandatory. Though IMO any end-user application strictly dependable on any init system is broken by design: for a daemon there should be no difference by which tool it was started. In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, You are wrong; systemd was created because Upstart had the silly CLA from Canonical[1], and because its authors wanted a novel init system for Linux (and Linux only) that used all the cool technologies the kernel provides, and that it could solve problems like: how to easily and consistently start daemons with well defined semantics for its dependencies; how to easily and consistently apply resource quotas to them; how to deal with modern computers where hardware comes and goes (including CPUs) all the time, etc. [2]. Excuse me please, but what you wrote above is very naive. All that reasons are just an excuse. The real reason is money: systemd is a Red Hat project (despite being formally open for everyone) and is their tool^Wweapon to fight with Canonical for a sales market. It the last years RH was pushed near even in a server market and now they are fighting back. They were lucky enough to acquire Poettiring guy and create from a simple and sound sysvinit (which is an important but not dictating peace of software) a key component where they can dictate their own line, where they can lead all Linux community in a way they need. That the real reason I despise systemd: in replaces the freedom of choice by a dictatorship of a small bunch of managers of a single corporation (yes, managers, not developers). And all this is under the veil of GPL and technical merits. This is the poison in the well of FOSS. Best regards, Andrew Savchenko pgpNXWRgUgRgH.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Sorry for entering others' dialog... On 17.02.2014 21:13, Canek Peláez Valdés wrote: On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl tansta...@libertytrek.org wrote: [snip] Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. I am not. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? I've never said it was easy. I said it could be done by someone willing and able. I repeated that like five times I think. I said it was done before; I never said it was easy. The whole point of creating new software is making things easier. Easier to use, easier to maintain, easier to remove. But it can be done, and that's a indisputable fact. A total ground-up rewrite of the whole Linux is also quite possible. It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. We really don't expect that systemd's authors do anything for us. Anything they do is not for us, thanks. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. For now it's not, but take a look into the future when not a single product will be published without systemd's support, just because it's everywhere -- and since it's everywhere, then why bother support anything other? Time, money... So it's a matter of time -- you'll personally be happy with this scenario -- at first -- but think further... They'll be able to stuff everything into it, making effectively a thing in itself which will dictate you where to go and what to do, just because you're not technically competent enough to deal with it -- hence more support calls and more $ etc etc. I don't believe in Red Hat's being a corporation of Good, nor any other corporation being such, and please remember the notorious examples of almost privatizing OSS by other 'corporations of Good'. (Android, MySQL, almost OpenOffice...) Well, there's some probability that by the time systemd occupies all linux distros, some clever RH guy (or a green soxx guy) will emerge and emerge systemd v2 which will be different ... But it's not something one should count on. [...] If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE it would happen. But don't complain if no one does, and it doesn't. That's your point -- and mine. We aren't complaining -- we want to prevent this. The forward-looking people must unite, it may sound ridiculous, against systemd -- not because of its design, technical details etc, but because otherwise in short time you'll end up comparing systemd to itself. You know what it is: everything's free but nothing to choose from. We had it before, it's called communism. Maybe it is not that bad but we don't want it anymore. Regards. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-17 12:52 PM, Andrew Savchenko birc...@gmail.com wrote: And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Forcefully? Are you saying that *anyone* can *force* Linus to put something into the kernel? I'd also really, *really* like to hear a *recent* opinion from Linus on systemd...
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 17/02/2014 17:29, Stroller wrote: On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon alan.mckin...@gmail.com wrote: ... Whatever problems Red Hat are trying to solve in the Red Hat space are problems that do not affect me, so I do not need Red Hat's solution. As for Gnome, I have yet to see a valid reason why Gnome *must* use systemd; that is simply not true at all. I thought this all boiled down to trying to login to GDM using accessibility functions and a bluetooth hearing aid (or bluetooth keyboard, for that matter). That was the classic rationale for no separate /usr without an initrd in udev - the claimed need to have any arbitrary runnable code available to be run before the entire system is up and running. Red Hat's reasons for pushing systemd are more fuzzy and nothing I've read so far tells me we have the full picture. Two things seem highly plausible: 1. An init system that can use modern features of the Linux kernel (most often Linux-only at this point) like cgroups 2. Extremely fast boot times to spin up virtual machines in a fraction of the time it currently takes. #1 may or may not be desirable, I honestly don't know. What I have seen is a lot of theory and not much reproducable fact. #2 is highly desirable if you run massive VM farms; folks like google, rh and amazon would be very interested. Doesn't really sound like a valid reason to consume and replace the entire existing ecosystem though. How many googles, red hats and amazons are out there versus how many regular joes like thee and me? Why didn't red hat just write their magic sauce to be non-intrusive? Profit and politics I suppose, I really don't see a valid overarching technical reason why it *must* be so. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 14:52:33 -0500 Tanstaafl wrote: On 2014-02-17 12:52 PM, Andrew Savchenko birc...@gmail.com wrote: And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Forcefully? Are you saying that *anyone* can *force* Linus to put something into the kernel? OK, my choice of words was not appropriate. I mean that not every kernel dev is happy that kdbus is in the kernel now. I'd also really, *really* like to hear a *recent* opinion from Linus on systemd... Judging from his previous opinions this one is unlikely to be systemd- friendly. Best regards, Andrew Savchenko pgpoH_OQWnQcJ.pgp Description: PGP signature
Re: [gentoo-user] JDK 7 on server
On Mon, 17 Feb 2014 08:57:46 -0800 Edward M. edwardm.gentoo.j...@live.com wrote: Sorry for top post using my phone Ice tea is Java se. Glass server uses Java EE because EE has added API and Runtime to build enterprise secure apps. sorry the link did not help. Sent from my Windows Phone From: Nilesh Govindrajanmailto:m...@nileshgr.com Sent: 2/17/2014 6:07 AM To: gentoo-user@lists.gentoo.orgmailto:gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] JDK 7 on server On Monday 17 February 2014 04:12 AM, Edward M wrote: On Sun, 16 Feb 2014 14:14:24 +0530 Nilesh Govindrajan m...@nileshgr.com wrote: rvices to customers, so compatibility is definitely a concern. I'm not exactly sure what the differences are between Oracle JDK OpenJDK; the differences I found so far on Google are old and make sense only for Java 6. Hello, To my understanding, Oracle JDK binary is created from the source code released from the OpenJDK project with some Oracle's own propriety code. The other difference is Oracle's JDK binary is released under Oracle Technology Network Developer License Terms for JAVA EE SDK,JDK where as OpenJDK code is under GPL + linking exceptions. More info at: https://blogs.oracle.com/henrik/entry/java_7_questions_answers Best regards ED So it would be correct to say that for Java EE applications, icedtea would be enough? I was not satisfied with the reply i sent earlier. I'm not used to yet used to typing on a smartphone yet. Java EE extends Java SE platform with added API for object relational mapping, distributed and multi-tier architecture, web services,etc. Making it more useful servers. where as icedtea is basically Java SE,and would be missing the added components for Glassfish server that Java EE contains. Found Java EE documentation from Oracle: http://www.oracle.com/technetwork/java/javaee/documentation/index.html http://docs.oracle.com/javaee/7/firstcup/doc/java-ee001.htm#GCRLZ As per the link you gave me, it says some graphical components fonts are extra, none of which are used in case of web applications. again sorry the link was not helpful Best regards ED -- Learing Linux with Gentoo to earn LPIC1.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko birc...@gmail.com wrote: On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs are bugs, period. And they get reported and fixed. Bugs in the critical system components are critical to the whole system. Yeah, that's why we have unit testing and QA teams and stable and unstable releases, etc. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. And the world will end? The same happens if the kernel has an error. That's why critical components should be as simple and clean as possible. Like the kernel? You call that simple? I'm sorry, but you are (IMO) wrong: critical components should be thoroughly tested and debugged, and have integrated unit testing, and a large enough group of volunteers to test new releases before they go into the general public. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. Also, again, systemd have a lot of little binaries, many of them optional. The LOC of PID 1 is actually closer to SysV (although still bigger). Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. FACT: almost no bug report in systemd involves a segfault in PID 1. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. kdbus uses a different wire protocol than dbus; but for clients that doesn't matter; libsystemd-dbus will offer a compatibility layer (talk about standard and replaceable), so if your application uses dbus today, it will work with kdbus. Of course, new applications will take advantage of the new features of kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Good for you. Guess what will be done in mine? Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, or Keith Packard of X.org fame? None of them works for Red Hat; both of them know more about Unix and Linux than you and me together, and both of them promote systemd. I mean, I myself know a thing or two about computing and Linux, and I promote systemd (and nobody pays me, BTW), but obviously you don't need to believe in my credentials. And, no offense, but I will always give more weight to the words of Greg Kroah-Hartman or Keith Packard (to name only two), instead of a random user in gentoo-user. There are knowledgeable people who are against systemd. But usually they don't give *technical* sound reasons. And all that science was ignored during systemd architecture process if there was any at all. You should read systemd-devel and Lennart's blog posts before saying something like that. I did. Regards -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 12:24 PM, Andrew Savchenko birc...@gmail.com wrote: On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote: It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. And here we have a small problem: for modules to be replaceable the core system should be designed to support replaceable modules, but systemd is not. You misunderstood me: I didn't mean to say that someone should write a module to replace one of systemd's modules. I mean that distributions and projects are using systemd's features, and that if you want those features to be easily and simply replaceable, then someone needs to write them like that. Systemd developers decided the tightly integrated route; if you don't like that, and that the distributions are using systemd's features, write something similar being easily and simply replaceable so the distros don't need to use systemd. The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. Well, then go and show them how it's done. And please don't say that it's already done, because if that were the case, no distro would have adopted systemd. They adopted it because of the features it offers. Just imagine that one have PCI-E bus and this bug is being replaced with some other PC-systemd bus, where one have to interface each component differently. And if one removes e.g. audio card some other seemingly independent component e.g. network controller becomes broken. That is the nature of systemd and that is many people dislike this technology. That is a broken analogy; if logind has a bug, that doesn't affect timedated, nor udev. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. The most sane and fair solution was already proposed: create a systemd profile for those who need it. I personally highly dislike systemd technology, but I respect the right of other to shoot them in the leg (or head) as much as they want to. This is Gentoo: a universal constructor providing people means to build any system in any shape they need. If someone willing and able provides any choice, that choice will be available. Unfortunately chances are that in future some software may become unusable or unsupported outside of systemd profile. But patches may be created and other profiles will continue to live the same way hardened exists now and will continue to exist later. Yeah, and that's my whole point: if you want that the world outside of systemd keeps working, you need to step in. Complaining about systemd will get no one nowhere. BTW it was shown at the recent LVEE Winter 2014 conference that GDM can be easily freed from systemd and OpenBSD guys have an interesting idea for faking systemd presence for applications requesting one mandatory. Though IMO any end-user application strictly dependable on any init system is broken by design: for a daemon there should be no difference by which tool it was started. GNOME depends on logind, not systemd. And no one has been willing and able to produce a compatible replacement: logind works with a dbus API, so it's (in theory) *easy* to duplicate its functionality. Ubuntu has been working in a replacement, but (AFAIU) is not finished. In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, You are wrong; systemd was created because Upstart had the silly CLA from Canonical[1], and because its authors wanted a novel init system for Linux (and Linux only) that used all the cool
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 12:28 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: Sorry for entering others' dialog... On 17.02.2014 21:13, Canek Peláez Valdés wrote: On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl tansta...@libertytrek.org wrote: [snip] Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. I am not. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? I've never said it was easy. I said it could be done by someone willing and able. I repeated that like five times I think. I said it was done before; I never said it was easy. The whole point of creating new software is making things easier. Easier to use, easier to maintain, easier to remove. Well, systemd is easier to use after a little time learning how it works. And it seems to be easier to maintain that thousands of lines of spaghetti shell code. And, I'm sorry, did you just said easier to remove? Seriously? You think the kernel is easier to remove? Or glibc? But it can be done, and that's a indisputable fact. A total ground-up rewrite of the whole Linux is also quite possible. Of course it is; that's the beauty of free (libre) software. It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You make a wrong comparison, because MS is not free (libre) software. With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we have been able to try new technologies (and see that some of them fail, like HAL [yuck!]), because we have the source. As you said, you can replace the whole of Linux if you so desire (and have the technical ability). You will never be able to do that with any MS software, and so the comparison makes no sense. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. We really don't expect that systemd's authors do anything for us. Anything they do is not for us, thanks. Sorry, but they do. Read the mailing list. Feature requests, bugs, they do it for their users. Every time a new distro chooses systemd as init, the developers try to help the maintainers to integrate systemd to it. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. For now it's not, but take a look into the future when not a single product will be published without systemd's support, just because it's everywhere -- and since it's everywhere, then why bother support anything other? Time, money... If enough people, willing and able, want to do it, they will. Look at ReactOS. Or Syllable. Or Hurd. Or Debian/kFreeBSD. The thing (and that's also my point), apparently *most* of the people willing and able to create cool software have decided that systemd is the way to go. And, even if you want to attribute that to a simple monetary issue, most of them do it *happily* because many things are just easier to do with systemd. So it's a matter of time -- you'll personally be happy with this scenario -- at first -- but think further... I do. All the time, since 1996 when I started using Linux. They'll be able to stuff everything into it, making effectively a thing in itself which will dictate you where
Re: [gentoo-user] JDK 7 on server
On 18 Feb 2014 06:04, Edward M edwardm.gentoo.j...@live.com wrote: On Mon, 17 Feb 2014 08:57:46 -0800 Edward M. edwardm.gentoo.j...@live.com wrote: Sorry for top post using my phone Ice tea is Java se. Glass server uses Java EE because EE has added API and Runtime to build enterprise secure apps. sorry the link did not help. Sent from my Windows Phone From: Nilesh Govindrajanmailto:m...@nileshgr.com Sent: 2/17/2014 6:07 AM To: gentoo-user@lists.gentoo.orgmailto:gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] JDK 7 on server On Monday 17 February 2014 04:12 AM, Edward M wrote: On Sun, 16 Feb 2014 14:14:24 +0530 Nilesh Govindrajan m...@nileshgr.com wrote: rvices to customers, so compatibility is definitely a concern. I'm not exactly sure what the differences are between Oracle JDK OpenJDK; the differences I found so far on Google are old and make sense only for Java 6. Hello, To my understanding, Oracle JDK binary is created from the source code released from the OpenJDK project with some Oracle's own propriety code. The other difference is Oracle's JDK binary is released under Oracle Technology Network Developer License Terms for JAVA EE SDK,JDK where as OpenJDK code is under GPL + linking exceptions. More info at: https://blogs.oracle.com/henrik/entry/java_7_questions_answers Best regards ED So it would be correct to say that for Java EE applications, icedtea would be enough? I was not satisfied with the reply i sent earlier. I'm not used to yet used to typing on a smartphone yet. Java EE extends Java SE platform with added API for object relational mapping, distributed and multi-tier architecture, web services,etc. Making it more useful servers. where as icedtea is basically Java SE,and would be missing the added components for Glassfish server that Java EE contains. Found Java EE documentation from Oracle: http://www.oracle.com/technetwork/java/javaee/documentation/index.html http://docs.oracle.com/javaee/7/firstcup/doc/java-ee001.htm#GCRLZ As per the link you gave me, it says some graphical components fonts are extra, none of which are used in case of web applications. again sorry the link was not helpful Best regards ED -- Learing Linux with Gentoo to earn LPIC1. No problem. Actually glassfish needs JDK7 as per their docs. So any JDK7 should work. Java EE is just a specification to be implemented by application servers.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 18:35:34 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko birc...@gmail.com wrote: On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs are bugs, period. And they get reported and fixed. Bugs in the critical system components are critical to the whole system. Yeah, that's why we have unit testing and QA teams and stable and unstable releases, etc. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. And the world will end? The same happens if the kernel has an error. That's why critical components should be as simple and clean as possible. Like the kernel? You call that simple? I'm sorry, but you are (IMO) wrong: critical components should be thoroughly tested and debugged, and have integrated unit testing, and a large enough group of volunteers to test new releases before they go into the general public. How can you be sure if something is large enough if, as you say below, you do not care about probabilities? SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. Also, again, systemd have a lot of little binaries, many of them optional. The LOC of PID 1 is actually closer to SysV (although still bigger). Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; If you do not care (= do not now anything) about probabilities (and mathematics, in general), you just unable to understand that debugging a program with 200K lines of code take 20!/(1!)^20 more time than debugging of 20 different programs with 10K lines of code. You can try to calculate that number yourself but I quite sure that if the latter can take, say, 20 days, the former can take millions of years. It is all the probability! Or, to be more precise, combinatorics. I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. Have you ever tried forex? If yes, you should have been warned that no past performance guarantee the future one. And if you do not believe that (and do not care about probability and all the stuff like that), you should visit any of the forex forums where you will be suggested a magical money winning strategy that, in the past, behaved very well and earned 200 or even 500% a month. FACT: almost no bug report in systemd involves a segfault in PID 1. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. kdbus uses a different wire protocol than dbus; but for clients that doesn't matter; libsystemd-dbus will offer a compatibility layer (talk about standard and replaceable), so if your application uses dbus today, it will work with kdbus. Of course, new applications will take advantage of the new features of kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. Lol, he seems to start to use the arguments like You even do not know my elder brother/acquaintance from the street nearby who can easily hit you down! So, here, I would like to thank everybody in this discussion who helped me to understand the danger of systemd and note that it is now became pointless to continue this discussion with this unpayed systemd promoter. anyway it is possible to disable this stuff in kernel and
Re: [gentoo-user] JDK 7 on server
On Tue, 18 Feb 2014 07:11:17 +0530 Nilesh Govindrajan m...@nileshgr.com wrote: No problem. Actually glassfish needs JDK7 as per their docs. So any JDK7 should work. Java EE is just a specification to be implemented by application servers. Yes Java EE extends Java SE platform with add ons, that is why i was not satisfied with the email i sent from my phone, i felt i was not being clear. I would suggest to use Oracle's JDK7 since it what glassfish calls for. that is what i'm using in Gentoo along with Netbeans,etc. Best Regards. Ed -- Learing Linux with Gentoo to earn LPIC1.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 3:53 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 17/02/2014 17:29, Stroller wrote: On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon alan.mckin...@gmail.com wrote: ... Whatever problems Red Hat are trying to solve in the Red Hat space are problems that do not affect me, so I do not need Red Hat's solution. As for Gnome, I have yet to see a valid reason why Gnome *must* use systemd; that is simply not true at all. I thought this all boiled down to trying to login to GDM using accessibility functions and a bluetooth hearing aid (or bluetooth keyboard, for that matter). That was the classic rationale for no separate /usr without an initrd in udev - the claimed need to have any arbitrary runnable code available to be run before the entire system is up and running. Red Hat's reasons for pushing systemd are more fuzzy and nothing I've read so far tells me we have the full picture. Two things seem highly plausible: 1. An init system that can use modern features of the Linux kernel (most often Linux-only at this point) like cgroups 2. Extremely fast boot times to spin up virtual machines in a fraction of the time it currently takes. #1 may or may not be desirable, I honestly don't know. What I have seen is a lot of theory and not much reproducable fact. init scripts, in general, are ad-hoc, quirky, and incomplete implementations of service supervision in bash. They're reliable so long as the daemon can be relied on to advertise one or all of its processes in a pid file. Thing is, there are way too many different possible setups for services for that to be the case. In the average case watching a PID file works. And since most people use average software, most people don't care. That's ok. Thing is an init isn't just for most people. It's for all people. It should be reliable for all services. I used to use cherokee. Fast, light, awesome, and with a web admin. The init script always failed me. /etc/init.d/cherokee stop was not a guaranteed stop to all forked cherokee processes - the parent pid dies, but some forked process or something, usually related to rrdtool, doesn't. Or the parent does exit and erases the pid file but it returns control immediately and its not yet done exiting. Something like that or other. Point is, I've several times had to ps aux|grep ... kill; zap; start - on production servers. Was it cherokee's fault? Maybe. But the init script should have told me that. Or even better, the init script should have done its job and terminted the processes. See, pid files are just a proxy, they don't work for all services and all setups. Maybe a process crashes before it kills its forks. Maybe the server has a restart feature that fails to write the pid file because the init script created it as root but the daemon relinquished privileges. Maybe there's a bug somewhere. Maybe the pid file gets overwritten accidentally. Maybe the pid file is stale because of a power failure. Point is you don't know until the service restart which should just take a sec costs you maybe an hour or two in billable time. With supervised cgroups that's not a problem. Because all process forks are grouped together, it doesn't matter if there's a pid file or not. When its kill time, the daemon and all forks and children go down. Because they're dynamically created on start, they don't get stale or point to the wrong process. Sounds to me like the right tool for the job. The init script introduces a point of fragility and brittleness into the system making it harder to debug, all to implement service supervision. If you look at the upstream docs of your daemon, it'll probably just tell you to run /usr/sbin/somethingd, maybe with a -d argument, to find out why it isn't starting. Cue the init script now always failing because you just created a bunch of files as the root user. Bit me in the back a few times with mysqld. Oh, I'm supposed to read the whole init script to determine all environment variables, settings, and switches the system uses to start a daemon, right? Good luck grepping. Because from a unit file, I can tell the command to run in a single glance. -- This email is:[ ] actionable [x] fyi[ ] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] JDK 7 on server
On Mon, 17 Feb 2014 18:41:18 -0800 Edward M edwardm.gentoo.j...@live.com wrote: On Tue, 18 Feb 2014 07:11:17 +0530 Nilesh Govindrajan m...@nileshgr.com wrote: No problem. Actually glassfish needs JDK7 as per their docs. So any JDK7 should work. Java EE is just a specification to be implemented by application servers. Yes Java EE extends Java SE platform with add ons, that is why i was not satisfied with the email i sent from my phone, i felt i was not being clear. I would suggest to use Oracle's JDK7 since it what glassfish calls for. that is what i'm using in Gentoo along with Netbeans,etc. Best Regards. Ed Nilesh, I also want to add, it has been pleasure conversing about Java with you and thank you for your patience. Best regards Ed -- Learing Linux with Gentoo to earn LPIC1.
[gentoo-user] LDAP server questions
Hello list! I'm planning to replace an Active Directory server currently functioning *only* as an LDAP server, with a dedicated Linux-based LDAP server. Now, the function of the LDAP server is at the moment: * Provide the settings database for Axigen email server * Provide group membership for BlueCoat proxy (who allowed to access what) * Provide group membership for FreeRADIUS * Provide group membership for Fortinet VPN The day-to-day management will be handled be another division, and I'm quite sure that they prefer a GUI, so the solution really should have a GUI support (either Windows-based 'client' or web-based admin console). Apparently, there are now many implementations of LDAP in the *nix world, such as OpenLDAP, OpenDS, ApacheDS, and 389DS. Have any of you experiences with them? Which one do you think is the most mature and supported? And, quite importantly, which one has a GUI front-end? Rgds, --
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 8:05 PM, Gevisz gev...@gmail.com wrote: [ snip ] How can you be sure if something is large enough if, as you say below, you do not care about probabilities? By writing correct code? SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. Also, again, systemd have a lot of little binaries, many of them optional. The LOC of PID 1 is actually closer to SysV (although still bigger). Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; If you do not care (= do not now anything) about probabilities (and mathematics, in general), you just unable to understand that debugging a program with 200K lines of code take 20!/(1!)^20 more time than debugging of 20 different programs with 10K lines of code. You can try to calculate that number yourself but I quite sure that if the latter can take, say, 20 days, the former can take millions of years. It is all the probability! Or, to be more precise, combinatorics. My PhD thesis (which I will defend in a few weeks) is in computer science, specifically computational geometry and combinatorics. But hey, thanks for the lesson. I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. Have you ever tried forex? If yes, you should have been warned that no past performance guarantee the future one. I never said that. I trust the quality of the code, measured by my own judgment and bug reports, etc. Not past performance. And even if a bug goes by, then what? The world will end? No, the bug will be reported, and fixed. And life will go on. And if you do not believe that (and do not care about probability and all the stuff like that), you should visit any of the forex forums where you will be suggested a magical money winning strategy that, in the past, behaved very well and earned 200 or even 500% a month. Thanks for the tip, but I have never understood the people that believes economics is closer to mathematics than sociology. FACT: almost no bug report in systemd involves a segfault in PID 1. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. kdbus uses a different wire protocol than dbus; but for clients that doesn't matter; libsystemd-dbus will offer a compatibility layer (talk about standard and replaceable), so if your application uses dbus today, it will work with kdbus. Of course, new applications will take advantage of the new features of kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. Lol, he seems to start to use the arguments like You even do not know my elder brother/acquaintance from the street nearby who can easily hit you down! If you don't think Greg's words have any weight in a Linux-related technical discussion, then I'm afraid we will need to agree to disagree on any technical subject. So, here, I would like to thank everybody in this discussion who helped me to understand the danger of systemd and note that it is now became pointless to continue this discussion with this unpayed systemd promoter. Getting personal, are we? anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Good for you. Guess what will be done in mine? Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, or Keith Packard of X.org fame? None of them works for Red Hat; both of them know more about Unix and Linux than you and me together, and both of them promote systemd. Aha! How could you even doubt my understanding the words of these prophets! :-) They, contrary to you, actually give technical arguments instead of splutter some nonsense about combinatorics that has nothing to do
Re: [gentoo-user] LDAP server questions
On 18 February 2014 06:03:02 CET, Pandu Poluan pa...@poluan.info wrote: Hello list! I'm planning to replace an Active Directory server currently functioning *only* as an LDAP server, with a dedicated Linux-based LDAP server. Now, the function of the LDAP server is at the moment: * Provide the settings database for Axigen email server * Provide group membership for BlueCoat proxy (who allowed to access what) * Provide group membership for FreeRADIUS * Provide group membership for Fortinet VPN The day-to-day management will be handled be another division, and I'm quite sure that they prefer a GUI, so the solution really should have a GUI support (either Windows-based 'client' or web-based admin console). Apparently, there are now many implementations of LDAP in the *nix world, such as OpenLDAP, OpenDS, ApacheDS, and 389DS. Have any of you experiences with them? Which one do you think is the most mature and supported? And, quite importantly, which one has a GUI front-end? Rgds, -- Openldap has a webbased gui: phpldapadmin. Both are in the tree. I use this myself for all the user accounts. Allowing me to only maintain a single repository for all the services and desktops. Not been able to get ms windows to authenticate against it though. But that requires further tools to be properly configured. (Think samba as a DC) -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
