Re: [gentoo-user] USE flags handling
On Saturday 02 August 2014 16:13:19 Stroller wrote: On Sat, 2 August 2014, at 2:35 pm, J. Roeleveld jo...@antarean.org wrote: ... Do you still have the bug numbers for this? I have a few machines without any sound support. If I can remove the entire sound system from it, it would save time during the updates. Please, Joost, I beg you, stop posting in HTML. Also your email is broken, I already asked you this yesterday off-list - since you neither complied then, nor told me to naff off, I assume that you're dropping messages. Actually, I wasn't ignoring you. It just took some time to find the actual cause. In the settings for KMail, I had the tick-boxes mentioning HTML off already. Took me till this morning to notice that in the edit-window, Rich Text was selected. (It acts like a button that is pushed in) If anyone can tell me how to configure that to *always* default to *off*, instead of remembering the last setting, that would help. -- Joost
Re: [gentoo-user] Re: USE flags handling
On Sunday 03 August 2014 00:38:34 Philip Webb wrote: 140802 Walter Dnes wrote: In Gentoo, *ANY* kde app which runs on the kde infrastructure requires phonon, and one of aqua/gstreamer/vlc, unless you resort to ugly hackery as per http://permalink.gmane.org/gmane.linux.gentoo.user/276393 So don't blame KDE, blame Gentoo for not handling Phonon correctly : see KDE bug 190601 Gentoo bug 265864 . +1 Had a look myself just now based on your other comments. KDE actually specifies how to build without any multimedia (audio and video) support: https://techbase.kde.org/Development/Tutorials/CMake#Command_Line_Variables cmake command line variable: KDE4_DISABLE_MULTIMEDIA=ON: Build KDE without any multimedia (audio and video) support. -- Joost
Re: [gentoo-user] Re: Recommendations for scheduler
On Saturday 02 August 2014 16:53:26 James wrote: Alan McKinnon alan.mckinnon at gmail.com writes: Well, we've found 2 projects that at least in part seek to achieve our general goals - chronos and Martin's new project. Why don't we both fool around with them for a bit and get a sense of what it will take to add features etc? Then we can meet back here and discuss. Always better to build on an existing foundation Mesos looks promising for a variety of (Apache) reasons. Some key technologies folks may want google about that are related: Quincy (fair schedular) Chronos (scheduler) Hadoop (scheduler) Hadoop not a scheduler. It's a framework for a Big Data clustered database. HDFS (clusterd file system) Unless it's changed recently, not suitable for anything else then Hadoop and contains a single point of failure. http://gpo.zugaina.org/sys-cluster/apache-hadoop-common Zookeeper (Fault tolerance) SPARK ( optimized for interative jobs where a datase is resued in many parallel operations (advanced math/science and many other apps.) https://spark.apache.org/ Dryad Torque Mpiche2 MPI Globus tookit mesos_tech_report.pdf It looks as though Amazon, google, facebook and many others large in the Cluster/Cloud arena are using Mesos..? So let's all post what we find, particularly in overlays. Unless you are dealing with Big Data projects, like Google, Facebook, Amazon, big banks,... you don't have much use for those projects. Mesos looks like a nice project, just like Hadoop and related are also nice. But for most people, they are as usefull as using Exalytics. A scheduler should not have a large set of dependencies that you wouldn't use otherwise. That makes Chronos a non-option to me. Martin's project looks promising, but doesn't store the schedules internally. For repeating schedules, like what Alan was describing, you need to put those into scripts and start those from an existing cron. Of the 2, I think improving Martin's project is the most likely option for me as it doesn't have additional dependencies and seems to be easily implemented. -- Joost
[gentoo-user] Re: Recommendations for scheduler
J. Roeleveld jo...@antarean.org wrote: Depends on the specific requirements. If you want: In a sense, most you require can be done with my mentioned schedule tool, although perhaps the usage is not in the way you expected. I reorder your points for a clearer explanation: - have schedules operate over multiple machines (eg. part run on database, some on a compute-cluster, some other bit making nice graphs and printing it,...) Since schedule can use TCP for communication, this should not be a problem if you let schedule-server listen world-wide (export SCHEDULE_SERVER_OPTS=-a0.0.0.0) For the actual scheduling you must setup your machines correspondingly: Queue on one machine the task doing the database access you want (with schedule -a[serveraddress] queue command_to_access_database) and similarly on the other machines. Of course, ssh or anything else can be used to do this without physically accessing the machines. Then, on one machine (not necessarily that of the server), you run an appropriate driver script. - time based start of a schedule - dependencies in said schedules and between schedules which can delay the actual start - stop of schedule if error occurs All this is not a problem, since the driver script is just a shell script which calls schedule to start the tasks, wait for them being finished and/or checking their exit status. This is perhaps inconvenient but has the advantage of being absolutely flexible: You can use all linux tools like sleep (or also use at or cron) to get any delays you want, do tests more powerful than checking the exit status etc. - ability to restart schedule from crashed point Running non-yet started jobs after a crash is not a problem - you just edit your driver script appropriately and restart it. Jobs which were already running need to be re-queued if they should be running again.
Re: [gentoo-user] Re: Recommendations for scheduler
On Sunday, August 03, 2014 07:50:57 AM Martin Vaeth wrote: J. Roeleveld jo...@antarean.org wrote: Depends on the specific requirements. If you want: In a sense, most you require can be done with my mentioned schedule tool, although perhaps the usage is not in the way you expected. I agree, based on a quick look. I reorder your points for a clearer explanation: snipped explanation A useful addition to your schedule-tool would be to store the scripts in a way that makes editing simpler and then add an editing tool to make this process simpler. Add monitoring (email alerts, webpage, front-end) to check the status of all the batch-jobs. I might be mistaken, but I think the server keeps the entire queue in-memory and when the process dies, the status is lost? Or is it kept somewhere? -- Joost
Re: [gentoo-user] Re: USE flags handling
On Sun, Aug 03, 2014 at 09:07:52AM +0200, Joost Roeleveld wrote On Sunday 03 August 2014 00:38:34 Philip Webb wrote: 140802 Walter Dnes wrote: In Gentoo, *ANY* kde app which runs on the kde infrastructure requires phonon, and one of aqua/gstreamer/vlc, unless you resort to ugly hackery as per http://permalink.gmane.org/gmane.linux.gentoo.user/276393 So don't blame KDE, blame Gentoo for not handling Phonon correctly : see KDE bug 190601 Gentoo bug 265864 . +1 Had a look myself just now based on your other comments. KDE actually specifies how to build without any multimedia (audio and video) support: https://techbase.kde.org/Development/Tutorials/CMake#Command_Line_Variables cmake command line variable: KDE4_DISABLE_MULTIMEDIA=ON: Build KDE without any multimedia (audio and video) The big question... what is multimedia? Would it be possible to build kde with image support (gif/png/jpeg/tiff/pdf/etc) without building in audio and video? I.e. how integrated is kde's graphics and multimedia? -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: USE flags handling
On Sunday, August 03, 2014 04:17:23 AM Walter Dnes wrote: On Sun, Aug 03, 2014 at 09:07:52AM +0200, Joost Roeleveld wrote On Sunday 03 August 2014 00:38:34 Philip Webb wrote: 140802 Walter Dnes wrote: In Gentoo, *ANY* kde app which runs on the kde infrastructure requires phonon, and one of aqua/gstreamer/vlc, unless you resort to ugly hackery as per http://permalink.gmane.org/gmane.linux.gentoo.user/276393 So don't blame KDE, blame Gentoo for not handling Phonon correctly : see KDE bug 190601 Gentoo bug 265864 . +1 Had a look myself just now based on your other comments. KDE actually specifies how to build without any multimedia (audio and video) support: https://techbase.kde.org/Development/Tutorials/CMake#Command_Line_Variable s cmake command line variable: KDE4_DISABLE_MULTIMEDIA=ON: Build KDE without any multimedia (audio and video) The big question... what is multimedia? Would it be possible to build kde with image support (gif/png/jpeg/tiff/pdf/etc) without building in audio and video? I.e. how integrated is kde's graphics and multimedia? The most common definition of multimedia is audio and video. Images is generally a different set. Also the description specifies audio and video specifically. It might be useful to modify the ebuild(s) to specify that option and see what happens. But I think that needs to be added to quite a few ebuilds and the related dependencies need to be modified as well. -- Joost
Re: [gentoo-user] Recommendations for scheduler
On 2 August 2014 5:10:43 AM AEST, Alan McKinnon alan.mckin...@gmail.com wrote: On 01/08/2014 19:50, Сергей wrote: Also you can have a look at anacron. Unfortunately, anacron doesn't suit my needs at all. Here's how anacron works: this bunch of job will all happen today regardless of what time it is. That's not what I need, I need something that has very little to do with time. Example: 1. Start backup job on db server A 2. When complete, copy backup to server B and do a test import 3. If import succeeds, move backup to permanent storage and log the fact 4. If import fails, raise an alert and trigger the whole cycle to start again at 1 Meanwhile, 1. All servers are regularly doing apt-get update and downloading .debs, and applying security packages. Delay this on the db server if a backup is in progress. Meanwhile there is the regular Friday 5am code-publish cycle and month-end finance runs - this is a DevOps environment. I'm not sure if its quite what you have in mind, and it comes with a bit of a steep learning curve, but cfengine might fit the bill. http://cfengine.com Bruce -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] a question about emerge --sync
Volker Armin Hemmann wrote: Am 02.08.2014 09:17, schrieb Dale: Volker Armin Hemmann wrote: Am 01.08.2014 16:30, schrieb behrouz khosravi: Hello everybody. I have a little bandwidth problem. I don't want to update my packages very frequently. Is it save to sync my portage not very often, say every month or two, so when I install something I wont be warned that some of my packages are outdated? In this manner I wont need to mask my packages, to prevent them from updating, right ? Thanks. . the longer you wait, the more problems you will have. So sync often. Installing the actual updates? On a weekly basis is a good rule of thumb. And don't use --pretend, use --ask. Portage has become slow as f over time. You don't want to waste time to let it do the same twice. Also: read the manual. You obviously haven't - or did not understand everything you read, so read again. For your own safety. Back when I was on dial-up, I did my updates on Monday I think it was. In the case of OOo, just downloading the tarball could take a couple days. Once a week is pretty good in my opinion as well. I'd be nervous about going months tho. On occasion that can get to be a bit much. If two nasty updates hit at the same time, it could get touchy. Dale :-) :-) . back when I was responsible to keep 250 net-junkies online, the longer I waited the worse the problems. And you only have so much time between different WoW raids... True. I think the official claim is that once a year updates are supported. However, we have seen people that wait that long, and sometimes not even that long, and encounter a update process that deals with two or three deal breakers. I can't recall the package names but I know a couple packages can be a hair puller on their own. When you add in two of them at the same time, it gets bad really fast. So you make a good point. That is the reason I wanted to do updates about every week when I was on dial-up. I might would go two weeks at times. Now that I have DSL, I update usually twice a week. If I am expecting say a upgrade of KDE in between, I may add one that week or just shuffle my schedule to make it include the KDE upgrades. I have found that the twice a week updates are usually easier than the weekly ones when I was on dial-up. The improvements in portage could account for some of that but still, avoiding having two major changes at the same time is a good idea. The devs do seem to try and spread those apart a little anyway. They can't hold them forever tho. While every day may be a bit much, waiting months has its own issues. Then again, someone missing their WoW game may be a issue of its own. They may get . . . angry. LOL Dale :-) :-)
Re: [gentoo-user] a question about emerge --sync
On 03/08/2014 13:04, Dale wrote: Volker Armin Hemmann wrote: Am 02.08.2014 09:17, schrieb Dale: Volker Armin Hemmann wrote: Am 01.08.2014 16:30, schrieb behrouz khosravi: Hello everybody. I have a little bandwidth problem. I don't want to update my packages very frequently. Is it save to sync my portage not very often, say every month or two, so when I install something I wont be warned that some of my packages are outdated? In this manner I wont need to mask my packages, to prevent them from updating, right ? Thanks. . the longer you wait, the more problems you will have. So sync often. Installing the actual updates? On a weekly basis is a good rule of thumb. And don't use --pretend, use --ask. Portage has become slow as f over time. You don't want to waste time to let it do the same twice. Also: read the manual. You obviously haven't - or did not understand everything you read, so read again. For your own safety. Back when I was on dial-up, I did my updates on Monday I think it was. In the case of OOo, just downloading the tarball could take a couple days. Once a week is pretty good in my opinion as well. I'd be nervous about going months tho. On occasion that can get to be a bit much. If two nasty updates hit at the same time, it could get touchy. Dale :-) :-) . back when I was responsible to keep 250 net-junkies online, the longer I waited the worse the problems. And you only have so much time between different WoW raids... True. I think the official claim is that once a year updates are supported. However, we have seen people that wait that long, and sometimes not even that long, and encounter a update process that deals with two or three deal breakers. I can't recall the package names but I know a couple packages can be a hair puller on their own. icu, libxml, libpng and how can we forget shudder hal /shudder and of course our recent friends python-exec as well as udev/upower-pm-utils When you add in two of them at the same time, it gets bad really fast. So you make a good point. That is the reason I wanted to do updates about every week when I was on dial-up. I might would go two weeks at times. Now that I have DSL, I update usually twice a week. If I am expecting say a upgrade of KDE in between, I may add one that week or just shuffle my schedule to make it include the KDE upgrades. I have found that the twice a week updates are usually easier than the weekly ones when I was on dial-up. The improvements in portage could account for some of that but still, avoiding having two major changes at the same time is a good idea. The devs do seem to try and spread those apart a little anyway. They can't hold them forever tho. While every day may be a bit much, waiting months has its own issues. Then again, someone missing their WoW game may be a issue of its own. They may get . . . angry. LOL I think the main problem with long gaps between updates isn't that stuff breaks in new weird, wonderful ways never seen before (although that can happen) The main problem is that you hit the same problems everyone else had and solved months before and now can't remember what the solution was! Or those who could help have forgotten about it, moved on and pay little attention If you update weekly or bi-weekly on ~arch or monthly on arch you probably hit issues at the tail end when problems are fresh in people;'s minds and you can get first-rate help right here -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Recommendations for scheduler
On 03/08/2014 11:27, Bruce Schultz wrote: On 2 August 2014 5:10:43 AM AEST, Alan McKinnon alan.mckin...@gmail.com wrote: On 01/08/2014 19:50, Сергей wrote: Also you can have a look at anacron. Unfortunately, anacron doesn't suit my needs at all. Here's how anacron works: this bunch of job will all happen today regardless of what time it is. That's not what I need, I need something that has very little to do with time. Example: 1. Start backup job on db server A 2. When complete, copy backup to server B and do a test import 3. If import succeeds, move backup to permanent storage and log the fact 4. If import fails, raise an alert and trigger the whole cycle to start again at 1 Meanwhile, 1. All servers are regularly doing apt-get update and downloading .debs, and applying security packages. Delay this on the db server if a backup is in progress. Meanwhile there is the regular Friday 5am code-publish cycle and month-end finance runs - this is a DevOps environment. I'm not sure if its quite what you have in mind, and it comes with a bit of a steep learning curve, but cfengine might fit the bill. http://cfengine.com Hi Bruce, Thanks for the reply. I only worked with cfengine once, briefly, years ago, and we quickly decided to roll our own deployment solution to solve that very specific vertical problem. Isn't cfengine a deployment framework, similar in ideals to puppet and chef? I don't want to deploy code or manage state, I want to run code (backups, database maintenance, repair of dodgy data in databases and code publish in a devops environment) -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: Recommendations for scheduler
J. Roeleveld jo...@antarean.org wrote: A useful addition to your schedule-tool would be to store the scripts in a way that makes editing simpler Since it is an arbitrary script in an arbitrary language, I think this is not in the scope of this project to do this. In most cases I used it so far, 1-2 more or less complex lines (maybe a few more if they would not be complex) in an interactive zsh were enough, and these are very simple enough to edit in zsh, i.e. I even did not write any script file in the classical sense. I might be mistaken, but I think the server keeps the entire queue in-memory and when the process dies, the status is lost? Yes, the server process must not die. If it dies, not only the queue is lost but also the waiting processes (that is: queued but not yet started) cannot be reached anymore: These waiting processes do not have their own TCP socket but just keep their established connection with the server's socket until the server tells them through this connection to start or to cancel; if this connection gets lost, the waiting processes die: What else could they do, reasonably? The already started processes have a unique ID (into which the server's process is encoded): They reestablish the connection to report the exit status according to this ID. If the server is stopped, they cannot report this status, of course, and moreover, a new server does not know their IDs either and thus will ignore these status reports. Maybe this protocol is not the most clever solution, but it is one which could be implemented without lots of overhead: Mainly, I was up to a quick solution which is working good enough for me: If the server has no bugs, why should it die? Moreover, if the server dies for some strange reasons, it is probably safer to re-queue the jobs again, anyway.
Re: [gentoo-user] Re: Recommendations for scheduler
On 03/08/2014 09:23, Joost Roeleveld wrote: On Saturday 02 August 2014 16:53:26 James wrote: Alan McKinnon alan.mckinnon at gmail.com writes: Well, we've found 2 projects that at least in part seek to achieve our general goals - chronos and Martin's new project. Why don't we both fool around with them for a bit and get a sense of what it will take to add features etc? Then we can meet back here and discuss. Always better to build on an existing foundation Mesos looks promising for a variety of (Apache) reasons. Some key technologies folks may want google about that are related: Quincy (fair schedular) Chronos (scheduler) Hadoop (scheduler) Hadoop not a scheduler. It's a framework for a Big Data clustered database. HDFS (clusterd file system) Unless it's changed recently, not suitable for anything else then Hadoop and contains a single point of failure. http://gpo.zugaina.org/sys-cluster/apache-hadoop-common Zookeeper (Fault tolerance) SPARK ( optimized for interative jobs where a datase is resued in many parallel operations (advanced math/science and many other apps.) https://spark.apache.org/ Dryad Torque Mpiche2 MPI Globus tookit mesos_tech_report.pdf It looks as though Amazon, google, facebook and many others large in the Cluster/Cloud arena are using Mesos..? So let's all post what we find, particularly in overlays. Unless you are dealing with Big Data projects, like Google, Facebook, Amazon, big banks,... you don't have much use for those projects. My wife works in BigData for real, she and Joost speak the same language, I don't :-) She reckons Big Data is like teenage sex - everyone says they are doing it and no-one really does ;-D Mesos looks like a nice project, just like Hadoop and related are also nice. But for most people, they are as usefull as using Exalytics. A bit OT, but it might be worthwhile for interested persons to get good ebuilds going for these projects. Someone will use it on Gentoo, and it will add value to the project. Much like gems and other business-oriented packages benefit A scheduler should not have a large set of dependencies that you wouldn't use otherwise. That makes Chronos a non-option to me. Martin's project looks promising, but doesn't store the schedules internally. For repeating schedules, like what Alan was describing, you need to put those into scripts and start those from an existing cron. Sounds like a small feature-add. If Martin did his groundwork correctly[1] then the core logic will work and it's just a case of adding some persistence and loading the data back in on demand Of the 2, I think improving Martin's project is the most likely option for me as it doesn't have additional dependencies and seems to be easily implemented. Don't forget Martins is the guy who does eix. Street cred? check Knows Gentoo? check [1] I only say it this way as I haven't evaluated his code at all yet so have no idea how far Martin has taken it -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] a question about emerge --sync
Alan McKinnon wrote: On 03/08/2014 13:04, Dale wrote: True. I think the official claim is that once a year updates are supported. However, we have seen people that wait that long, and sometimes not even that long, and encounter a update process that deals with two or three deal breakers. I can't recall the package names but I know a couple packages can be a hair puller on their own. icu, libxml, libpng and how can we forget shudder hal /shudder and of course our recent friends python-exec as well as udev/upower-pm-utils Oh goodness, you wouldn't mention *THAT* one. :-@ lol Those are the ones I was thinking of tho. Those can be a bit tricky at best. At least they were before. It seems portage handles things better now but why ask for trouble? You know, hal is the only reason, other than smoke coming from a power supply, that I have ever had to actually pull the plug on a puter. Ever. Hitting the rest button, a couple times. Pulling the plug, not for anything outside that smoke issue. I cleaned the power supply with air and a rubber band was caught in the fan. It ran for a bit but got a little toasty at the end. ;-) It seems that fan runs for a good reason. :/ When you add in two of them at the same time, it gets bad really fast. So you make a good point. That is the reason I wanted to do updates about every week when I was on dial-up. I might would go two weeks at times. Now that I have DSL, I update usually twice a week. If I am expecting say a upgrade of KDE in between, I may add one that week or just shuffle my schedule to make it include the KDE upgrades. I have found that the twice a week updates are usually easier than the weekly ones when I was on dial-up. The improvements in portage could account for some of that but still, avoiding having two major changes at the same time is a good idea. The devs do seem to try and spread those apart a little anyway. They can't hold them forever tho. While every day may be a bit much, waiting months has its own issues. Then again, someone missing their WoW game may be a issue of its own. They may get . . . angry. LOL I think the main problem with long gaps between updates isn't that stuff breaks in new weird, wonderful ways never seen before (although that can happen) The main problem is that you hit the same problems everyone else had and solved months before and now can't remember what the solution was! Or those who could help have forgotten about it, moved on and pay little attention If you update weekly or bi-weekly on ~arch or monthly on arch you probably hit issues at the tail end when problems are fresh in people;'s minds and you can get first-rate help right here That is a good point. At times when I see a upgrade issue mentioned here on the list, I wait a bit about my updates. Once things settle, bugs get worked out etc etc, then I upgrade mine with notes on how to fix a issue should it arise. Sometimes I wish folks could have a option for a third tier of the tree. One that is a month or so further behind for those that really need stable at all costs and minimal upgrade issues. Of course, that's not the Gentoo way tho. ;-) Dale :-) :-)
[gentoo-user] Enable password echo during login
Does someone know how to enable the echoing of passwords when logging in? I mean in the console or terminal. By default there's nothing displayed. I'd like to have the more traditional method of displaying asterisks instead. Possible?
Re: [gentoo-user] Enable password echo during login
I don't think normal login utility allow this. Unix never does this. Look at the Getty, login man pages but I really don't think it is possible. Le 3 août 2014 à 14:49, Nikos Chantziaras rea...@gmail.com a écrit : Does someone know how to enable the echoing of passwords when logging in? I mean in the console or terminal. By default there's nothing displayed. I'd like to have the more traditional method of displaying asterisks instead. Possible?
Re: [gentoo-user] Enable password echo during login
I think it's not possible On Aug 3, 2014 7:50 PM, Nikos Chantziaras rea...@gmail.com wrote: Does someone know how to enable the echoing of passwords when logging in? I mean in the console or terminal. By default there's nothing displayed. I'd like to have the more traditional method of displaying asterisks instead. Possible?
Re: [gentoo-user] Recommendations for scheduler
On 8/2/2014 5:33 AM, Alan McKinnon alan.mckin...@gmail.com wrote: I have an unusual boss. He's a business owner and quite naturally profit-driven. He also employs smart people and expects us to maintain systems in-house. He's also a zealous FLOSS fan. So when I present him a price tag for software his first question is always is there any free as in freedom software suited for the job? I'm still trying to wrap my brains around dealing with a boss that thinks like this:-) I am *sooo* jealous... ;)
Re: [gentoo-user] Enable password echo during login
There is one possibility: modify the login app code to display stars ;) Le 3 août 2014 à 15:02, Anan Laksmana ananda.laksm...@gmail.com a écrit : I think it's not possible On Aug 3, 2014 7:50 PM, Nikos Chantziaras rea...@gmail.com wrote: Does someone know how to enable the echoing of passwords when logging in? I mean in the console or terminal. By default there's nothing displayed. I'd like to have the more traditional method of displaying asterisks instead. Possible?
Re: [gentoo-user] Enable password echo during login
On Sunday 03 Aug 2014 14:05:42 Godzil wrote: There is one possibility: modify the login app code to display stars ;) Le 3 août 2014 à 15:02, Anan Laksmana ananda.laksm...@gmail.com a écrit : I think it's not possible Please do not top post. On Aug 3, 2014 7:50 PM, Nikos Chantziaras rea...@gmail.com wrote: Does someone know how to enable the echoing of passwords when logging in? I mean in the console or terminal. By default there's nothing displayed. I'd like to have the more traditional method of displaying asterisks instead. Do you mean like some GUI display managers do? Possible? Yes possible, BUT ... you'll probably need to create an alias and use echo (in combination with read?) to get it to print * in the place of characters. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Recommendations for scheduler
On Sunday, August 03, 2014 02:16:37 PM Alan McKinnon wrote: On 03/08/2014 09:23, Joost Roeleveld wrote: On Saturday 02 August 2014 16:53:26 James wrote: Alan McKinnon alan.mckinnon at gmail.com writes: snipped Unless you are dealing with Big Data projects, like Google, Facebook, Amazon, big banks,... you don't have much use for those projects. My wife works in BigData for real, she and Joost speak the same language, I don't :-) She reckons Big Data is like teenage sex - everyone says they are doing it and no-one really does ;-D I know a few companies that actually do use it. But, the biggest issue with the whole Big Data thing is that noone really agrees on what it actually is. Mesos looks like a nice project, just like Hadoop and related are also nice. But for most people, they are as usefull as using Exalytics. A bit OT, but it might be worthwhile for interested persons to get good ebuilds going for these projects. Someone will use it on Gentoo, and it will add value to the project. Much like gems and other business-oriented packages benefit I agree, but just to implement a decent scheduler, I still think it's overkill. A scheduler should not have a large set of dependencies that you wouldn't use otherwise. That makes Chronos a non-option to me. Martin's project looks promising, but doesn't store the schedules internally. For repeating schedules, like what Alan was describing, you need to put those into scripts and start those from an existing cron. Sounds like a small feature-add. If Martin did his groundwork correctly[1] then the core logic will work and it's just a case of adding some persistence and loading the data back in on demand The code looks clean and I think it shouldn't be too much work to add it. Of the 2, I think improving Martin's project is the most likely option for me as it doesn't have additional dependencies and seems to be easily implemented. Don't forget Martins is the guy who does eix. Street cred? check Knows Gentoo? check [1] I only say it this way as I haven't evaluated his code at all yet so have no idea how far Martin has taken it The code is clean and does what Martin says it does. -- Joost
Re: [gentoo-user] Re: Recommendations for scheduler
On Sunday, August 03, 2014 12:10:49 PM Martin Vaeth wrote: J. Roeleveld jo...@antarean.org wrote: A useful addition to your schedule-tool would be to store the scripts in a way that makes editing simpler Since it is an arbitrary script in an arbitrary language, I think this is not in the scope of this project to do this. In most cases I used it so far, 1-2 more or less complex lines (maybe a few more if they would not be complex) in an interactive zsh were enough, and these are very simple enough to edit in zsh, i.e. I even did not write any script file in the classical sense. I might be mistaken, but I think the server keeps the entire queue in-memory and when the process dies, the status is lost? Yes, the server process must not die. If it dies, not only the queue is lost but also the waiting processes (that is: queued but not yet started) cannot be reached anymore: These waiting processes do not have their own TCP socket but just keep their established connection with the server's socket until the server tells them through this connection to start or to cancel; if this connection gets lost, the waiting processes die: What else could they do, reasonably? The already started processes have a unique ID (into which the server's process is encoded): They reestablish the connection to report the exit status according to this ID. If the server is stopped, they cannot report this status, of course, and moreover, a new server does not know their IDs either and thus will ignore these status reports. Maybe this protocol is not the most clever solution, but it is one which could be implemented without lots of overhead: Mainly, I was up to a quick solution which is working good enough for me: If the server has no bugs, why should it die? Moreover, if the server dies for some strange reasons, it is probably safer to re-queue the jobs again, anyway. With the kind of schedules I am working with (and I believe Alan will also end up with), restarting the whole process from the start can lead to issues. Finding out how far the process got before the service crashed can become rather complex. -- Joost
Re: [gentoo-user] Re: USE flags handling
On 03/08/2014 04:59, Walter Dnes wrote: phonon is not an okular dependency. It is a deep dependancy. kde-base/kdelibs-4.12.5-r1.ebuild has a COMMONDEPEND= block which includes =media-libs/phonon-4.4.3. And media-libs/phonon-4.6.0-r1.ebuild has the following line... REQUIRED_USE=|| ( aqua gstreamer vlc ) In gentoo, *ANY* kde app which runs on the kde infrastructure requires phonon, and one of aqua/gstreamer/vlc, unless you resort to ugly hackery as per http://permalink.gmane.org/gmane.linux.gentoo.user/276393 OK. But my original point still stands: Okular is not designed to be a stand-alone app, it is designed to run in the context of something bigger. And that context is KDE. KDE is a full-featured desktop environment, it assumes that the user will want phonon and everything that comes with it, plus plasma. So when you emerge okular and get a boat load of new deps pulled in, why are you surprised when that goes the way it is designed, the way it says on the box? It's not a stand-alone app. This is also not Windows, here you have choices and there's no shortage of pdf readers out there. Pick another one -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Amd_Arm64 hardware shipping!
The ARMvaLuTion is coming to a linux system near you! The AMD Opteron A1100 Series development kit as it is known, provides the hardware and software necessary to begin application development and evaluate AMD Opteron A1100 Series processors. This a huge deal because the availability of the kit makes AMD is the only provider to offer the standard ARM Cortex-A57 technology and 64-bit ARM server hardware with complete ARMv8 instruction set support. http://www.forbes.com/sites/marcochiappetta/2014/07/31/amd-opteron-64-bit-arm-based-seattle-dev-kits-are-shipping/?partner=yahootix enjoy! James
Re: [gentoo-user] Re: Recommendations for scheduler
On 03/08/2014 15:36, J. Roeleveld wrote: Maybe this protocol is not the most clever solution, but it is one which could be implemented without lots of overhead: Mainly, I was up to a quick solution which is working good enough for me: If the server has no bugs, why should it die? Moreover, if the server dies for some strange reasons, it is probably safer to re-queue the jobs again, anyway. With the kind of schedules I am working with (and I believe Alan will also end up with), restarting the whole process from the start can lead to issues. Finding out how far the process got before the service crashed can become rather complex. Yes, very much so. My first concern is the database cleanups - without scheduler guarantees I'd need transactions in MySQL. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Recommendations for scheduler
On Sunday, August 03, 2014 10:04:50 PM Alan McKinnon wrote: On 03/08/2014 15:36, J. Roeleveld wrote: Maybe this protocol is not the most clever solution, but it is one which could be implemented without lots of overhead: Mainly, I was up to a quick solution which is working good enough for me: If the server has no bugs, why should it die? Moreover, if the server dies for some strange reasons, it is probably safer to re-queue the jobs again, anyway. With the kind of schedules I am working with (and I believe Alan will also end up with), restarting the whole process from the start can lead to issues. Finding out how far the process got before the service crashed can become rather complex. Yes, very much so. My first concern is the database cleanups - without scheduler guarantees I'd need transactions in MySQL. Or you migrate to PostgreSQL, but that is OT :) -- Joost
Re: [gentoo-user] Re: Recommendations for scheduler
On 03/08/2014 22:23, J. Roeleveld wrote: On Sunday, August 03, 2014 10:04:50 PM Alan McKinnon wrote: On 03/08/2014 15:36, J. Roeleveld wrote: Maybe this protocol is not the most clever solution, but it is one which could be implemented without lots of overhead: Mainly, I was up to a quick solution which is working good enough for me: If the server has no bugs, why should it die? Moreover, if the server dies for some strange reasons, it is probably safer to re-queue the jobs again, anyway. With the kind of schedules I am working with (and I believe Alan will also end up with), restarting the whole process from the start can lead to issues. Finding out how far the process got before the service crashed can become rather complex. Yes, very much so. My first concern is the database cleanups - without scheduler guarantees I'd need transactions in MySQL. Or you migrate to PostgreSQL, but that is OT :) Maybe, but also valid :-) I took one look at the schemas here and wondered Why MySQL? This is Postgres territory. It's a case of LAMP tunnel vision. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Recommendations for scheduler
On Sunday, August 03, 2014 10:57:06 PM Alan McKinnon wrote: On 03/08/2014 22:23, J. Roeleveld wrote: On Sunday, August 03, 2014 10:04:50 PM Alan McKinnon wrote: On 03/08/2014 15:36, J. Roeleveld wrote: Maybe this protocol is not the most clever solution, but it is one which could be implemented without lots of overhead: Mainly, I was up to a quick solution which is working good enough for me: If the server has no bugs, why should it die? Moreover, if the server dies for some strange reasons, it is probably safer to re-queue the jobs again, anyway. With the kind of schedules I am working with (and I believe Alan will also end up with), restarting the whole process from the start can lead to issues. Finding out how far the process got before the service crashed can become rather complex. Yes, very much so. My first concern is the database cleanups - without scheduler guarantees I'd need transactions in MySQL. Or you migrate to PostgreSQL, but that is OT :) Maybe, but also valid :-) I took one look at the schemas here and wondered Why MySQL? This is Postgres territory. It's a case of LAMP tunnel vision. That and that people who start with LAMP don't learn SQL. This leads to code that is near impossible to port to a different database and when people actually want to do all the work to get the SQL to work on any database, the projects involved refuse the patches. -- Joost
Re: [gentoo-user] USE flags handling
140803 Joost Roeleveld wrote: In the settings for KMail, I had the tick-boxes mentioning HTML off already. Took me till this morning to notice that in the edit-window, Rich Text was selected. (It acts like a button that is pushed in) If anyone can tell me how to configure that to *always* default to *off*, instead of remembering the last setting, that would help. Have you tried Mutt (smile) ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Recommendations for scheduler
On 3 August 2014 10:08:39 PM AEST, Alan McKinnon alan.mckin...@gmail.com wrote: On 03/08/2014 11:27, Bruce Schultz wrote: On 2 August 2014 5:10:43 AM AEST, Alan McKinnon alan.mckin...@gmail.com wrote: On 01/08/2014 19:50, Сергей wrote: Also you can have a look at anacron. Unfortunately, anacron doesn't suit my needs at all. Here's how anacron works: this bunch of job will all happen today regardless of what time it is. That's not what I need, I need something that has very little to do with time. Example: 1. Start backup job on db server A 2. When complete, copy backup to server B and do a test import 3. If import succeeds, move backup to permanent storage and log the fact 4. If import fails, raise an alert and trigger the whole cycle to start again at 1 Meanwhile, 1. All servers are regularly doing apt-get update and downloading .debs, and applying security packages. Delay this on the db server if a backup is in progress. Meanwhile there is the regular Friday 5am code-publish cycle and month-end finance runs - this is a DevOps environment. I'm not sure if its quite what you have in mind, and it comes with a bit of a steep learning curve, but cfengine might fit the bill. http://cfengine.com Hi Bruce, Thanks for the reply. I only worked with cfengine once, briefly, years ago, and we quickly decided to roll our own deployment solution to solve that very specific vertical problem. Isn't cfengine a deployment framework, similar in ideals to puppet and chef? I don't want to deploy code or manage state, I want to run code (backups, database maintenance, repair of dodgy data in databases and code publish in a devops environment) Cfengine can run arbitrary commands at scheduled times, so it is capable as a replacment for cron. It also has package management built in for your package updates. It is in the same vein as chef puppet, but deployment framework is not the way I would describe it. Deployment is only be a subset of what you can do with it. Cfengine3 was a major rewrite over version 2. The community edition is open source and should be available in Debian. The gentoo ebuild is a bit out of date currently. It also comes as a supported enterprise version which adds some sort of framework around the core - I've never personally looked into the enterprise features though. Bruce -- :B
Re: [gentoo-user] USE flags handling
On Sun, 3 August 2014, at 7:49 am, Joost Roeleveld jo...@antarean.org wrote: ... Actually, I wasn't ignoring you. It just took some time to find the actual cause. My apologies, Joost. It was driving me crazy. Stroller.
Re: [gentoo-user] USE flags handling
On Sun, 2014-08-03 at 08:49 +0200, Joost Roeleveld wrote: If anyone can tell me how to configure that to *always* default to *off*, instead of remembering the last setting, that would help. It's been a while since I used kmail (i always had issues and ended up reverting to thunderbird) but i'm pretty certain that the composer options allow you to disable rich-text for messages (or, conversely, enable plain-text-only). it's there somewhere, just dig ;) -- wraeth wra...@wraeth.id.au
Re: [gentoo-user] USE flags handling
On Sun, 3 August 2014, at 9:17 am, Walter Dnes waltd...@waltdnes.org wrote: … KDE actually specifies how to build without any multimedia (audio and video) support: https://techbase.kde.org/Development/Tutorials/CMake#Command_Line_Variables cmake command line variable: KDE4_DISABLE_MULTIMEDIA=ON: Build KDE without any multimedia (audio and video) The big question... what is multimedia? Would it be possible to build kde with image support (gif/png/jpeg/tiff/pdf/etc) without building in audio and video? I.e. how integrated is kde's graphics and multimedia? From a quick google for KDE4_DISABLE_MULTIMEDIA it looks like that just enables / disables Phonon: • http://mail.kde.org/pipermail/kde-buildsystem/2010-March/006806.html • http://www.filewatcher.com/p/kdebase-runtime-4.1.3.tar.bz2.52251161/kdebase-runtime-4.1.3/phonon/CMakeLists.txt.html I have to confess, I don't follow desktop development to know myself what Phonon means. The page linked to in the package description for media-libs/phonon is, unsurprisingly, uninformative: https://projects.kde.org/projects/kdesupport/phonon Stroller.
Re: [gentoo-user] USE flags handling
wraeth wrote: On Sun, 2014-08-03 at 08:49 +0200, Joost Roeleveld wrote: If anyone can tell me how to configure that to *always* default to *off*, instead of remembering the last setting, that would help. It's been a while since I used kmail (i always had issues and ended up reverting to thunderbird) but i'm pretty certain that the composer options allow you to disable rich-text for messages (or, conversely, enable plain-text-only). it's there somewhere, just dig ;) I used to use Kmail but switched to Seamonkey. Don't start. I might bite. :-) I did some googling and found where some others were complaining about this setting not sticking. It seems this is not a new issue. One bug dated all the way back to KDE3 stuff. I found another that was KDE4 which claims it was fixed, heard that before. lol So, maybe some bug got thrown back in? If after the next update it does the same, I throw up a can of Raid. Uh, over at KDE tho. ;-) Dale :-) :-)
