Re: [opensuse] openSUSE-13.1: at 17:00 system begins thrashing: What is cause?
On 2014-11-20 03:44, John Andersen wrote:
On 11/19/2014 06:32 PM, Carlos E. R. wrote:
Yes. But you can choose the time it normally runs.
Where is that choice made? Took a brief look, and didn't find much, I got lost in layers of indirection and gave up in despair! ;-)
If your openSUSE is recent enough, here: /etc/sysconfig/cron: # # At which time cron.daily should start. Default is 15 minutes after booting # the system. Due to the fact that cron script runs only every 15 minutes, # it will only run on xx:00, xx:15, xx:30, xx:45, not at the accurate time # you set. DAILY_TIME="22:10" ## Type: integer ## Default: 5 # Type: integer (days) # Default: 5 # # Maximum days not running when using a fixed time set in DAILY_TIME. # 0 to skip this. This is for users who will power off their system. # # There is a fixed max. of 14 days set, if you want to override this # change MAX_NOT_RUN_FORCE in /usr/lib/cron/run-crons MAX_NOT_RUN="2" -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/19/2014 06:54 PM, Carlos E. R. wrote:
On 2014-11-20 03:44, John Andersen wrote:
On 11/19/2014 06:32 PM, Carlos E. R. wrote:
Yes. But you can choose the time it normally runs.
Where is that choice made? Took a brief look, and didn't find much, I got lost in layers of indirection and gave up in despair! ;-)
If your openSUSE is recent enough, here:
/etc/sysconfig/cron:
# # At which time cron.daily should start. Default is 15 minutes after booting # the system. Due to the fact that cron script runs only every 15 minutes, # it will only run on xx:00, xx:15, xx:30, xx:45, not at the accurate time # you set. DAILY_TIME="22:10"
## Type: integer ## Default: 5 # Type: integer (days) # Default: 5 # # Maximum days not running when using a fixed time set in DAILY_TIME. # 0 to skip this. This is for users who will power off their system. # # There is a fixed max. of 14 days set, if you want to override this # change MAX_NOT_RUN_FORCE in /usr/lib/cron/run-crons MAX_NOT_RUN="2"
Well, its 13.2 so I hope that is recent enough ;-) I was more interested in the setting of time of he individual jobs that are scheduled for the system on a daily or hourly basis, etc. For instance I see in /etc/cron.daily/ jobs to check the battery backup rpmdb, etc. But they don't seem to have times associated with them. - -- After all is said and done, more is said than done. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRtWsoACgkQv7M3G5+2DLI7EwCfc3+Nh4pu0I6EAG5ec/yall27 fdAAn05CBdJ9xgqh7s4FTWWTp3/EWIgq =XqvL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-11-20 04:06, John Andersen wrote:
On 11/19/2014 06:54 PM, Carlos E. R. wrote:
Well, its 13.2 so I hope that is recent enough ;-)
I don't know that one personally that much :-p
I was more interested in the setting of time of he individual jobs that are scheduled for the system on a daily or hourly basis, etc.
Oh. No, there is no setting for that. It would need a complete redesign.
For instance I see in /etc/cron.daily/ jobs to check the battery backup rpmdb, etc. But they don't seem to have times associated with them.
No. The idea is to ensure that all those jobs run at least once a day, not when. Then they modified the script so that the loops starts at a preferred time, if the computer is connected at that hour. If not, it tries again next day, and the next... up to 14 days (configurable), then it runs at the first chance. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 11/19/2014 10:20 PM, Carlos E. R. wrote:
I was more interested in the setting of time of he individual jobs that are scheduled for the system on a daily or hourly basis, etc. Oh. No, there is no setting for that. It would need a complete redesign.
Yes, that's the problem with this implementation. It BANG! BANG! BANG! BANG! one after the other. You can't, as John asks, determine the time each specific one runs at. You can only set the time that cron.{daily,weekly,monthly} runs at, and that to 15 minute granularity. You can't, as is possible with both the real cron and with the systemd timer, run something "only on Monday" or "not on weekends" or "on the last Friday of the month". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-11-20 04:38, Anton Aylward wrote:
On 11/19/2014 10:20 PM, Carlos E. R. wrote:
I was more interested in the setting of time of he individual jobs that are scheduled for the system on a daily or hourly basis, etc. Oh. No, there is no setting for that. It would need a complete redesign.
Yes, that's the problem with this implementation. It BANG! BANG! BANG! BANG! one after the other. You can't, as John asks, determine the time each specific one runs at. You can only set the time that cron.{daily,weekly,monthly} runs at, and that to 15 minute granularity.
You can't, as is possible with both the real cron and with the systemd timer, run something "only on Monday" or "not on weekends" or "on the last Friday of the month".
If you need that degree of customization, just take those jobs out, probably by taking out the scripts from the daily folder, and create an enties for them in /etc/cron.d/mycustom instead, line per line. Not in /etc/crontab, because that has problems with updates. But the distribution has to cater for the majority, and what it has is a compromise that works for most people. As always :-) For me it works just fine :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 11/19/2014 10:50 PM, Carlos E. R. wrote:
If you need that degree of customization, just take those jobs out, probably by taking out the scripts from the daily folder, and create an enties for them in /etc/cron.d/mycustom instead, line per line. Not in /etc/crontab, because that has problems with updates.
Er ... NOT! Or "not-Quite" You are correct that updates will 'restore' /etc/crontab[1] but they will also restore the scripts you/I took out of the daily folder. The best I can think of is to replace those scripts you've taken out of daily with ones of the same name that are empty files (or non executable) and hope that the update produces .rpmnew ones that don't actually over-write them. I'm not sufficiently knowledgeable about how the system decides to create a .rpmnew/.rpmold rather than simply replace a file. [1] Will that? Won't we get a .rpmnew? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward
On 11/19/2014 10:20 PM, Carlos E. R. wrote:
I was more interested in the setting of time of he individual jobs that are scheduled for the system on a daily or hourly basis, etc. Oh. No, there is no setting for that. It would need a complete redesign.
Yes, that's the problem with this implementation. It BANG! BANG! BANG! BANG! one after the other. You can't, as John asks, determine the time each specific one runs at. You can only set the time that cron.{daily,weekly,monthly} runs at, and that to 15 minute granularity.
You can't, as is possible with both the real cron and with the systemd timer, run something "only on Monday" or "not on weekends" or "on the last Friday of the month".
And then there is: at man at and, of course: nqs (not built for openSUSE) http://gnqs.sourceforge.net/downloads/index.html -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/20/2014 04:54 AM, Carlos E. R. wrote:
# it will only run on xx:00, xx:15, xx:30, xx:45, not at the accurate time # you set. ................
- presently, on T'Weed oS 13.2 : scheduled cron jobs in /var/spool/cron/tabs/root - do seem to run at specified time { like 12:37 & 12:40 } ........... regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-11-20 05:16, Anton Aylward wrote:
On 11/19/2014 10:50 PM, Carlos E. R. wrote:
If you need that degree of customization, just take those jobs out, probably by taking out the scripts from the daily folder, and create an enties for them in /etc/cron.d/mycustom instead, line per line. Not in /etc/crontab, because that has problems with updates.
Er ... NOT! Or "not-Quite"
You are correct that updates will 'restore' /etc/crontab[1] but they will also restore the scripts you/I took out of the daily folder.
Of course it will.
The best I can think of is to replace those scripts you've taken out of daily with ones of the same name that are empty files (or non executable) and hope that the update produces .rpmnew ones that don't actually over-write them.
Or mark noexec. This can be done in the local permission file, so it is automatic. I don't remember if marking noexec works or not, though. Or create a weekly job that undoes things :-)
I'm not sufficiently knowledgeable about how the system decides to create a .rpmnew/.rpmold rather than simply replace a file.
Up to the people that create the new rpm, I think. The logic is not very sane, often the non-replaced file has an empty diff. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-11-20 10:34, ellanios82 wrote:
On 11/20/2014 04:54 AM, Carlos E. R. wrote:
# it will only run on xx:00, xx:15, xx:30, xx:45, not at the accurate time # you set. ................
- presently, on T'Weed oS 13.2 : scheduled cron jobs in
/var/spool/cron/tabs/root
- do seem to run at specified time { like 12:37 & 12:40 }
...........
Obviously, as that is a real cron job file. Or crontab. But the scripts placed in /etc/cron.daily (weekly, monthly) are not. They are run by a special concoction of one single cronjob and clever SUSE script called run-cruns. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
El 20/11/14 a las 00:06, John Andersen escribió:
Well, its 13.2 so I hope that is recent enough ;-)
I was more interested in the setting of time of he individual jobs that are scheduled for the system on a daily or hourly basis, etc.
You can do that with systemd timers functionality, though you can't just put these jobs there..you will have to: a) Rewrite everything or.. b) Use something called systemd-cron which acts as a translator from crontabs to systemd units. This is a third party addon, as introducing this bridge between incompatible worlds was rejected for inclusion in systemd. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/19/2014 10:06 PM, John Andersen wrote:
I was more interested in the setting of time of he individual jobs that are scheduled for the system on a daily or hourly basis, etc.
For instance I see in /etc/cron.daily/ jobs to check the battery backup rpmdb, etc. But they don't seem to have times associated with them.
Right. That don't have INDIVIDUAL times associated with them. EVERYTHING in the /etc/cron.daily/* gets run at the time set in /etc/sysconfig/cron, as I've discussed elsewhere. Carlos makes a good case as to why use this based on the idea that Desktop Uses is really a PC class OS and not a 24/7 server class OS. However I don't see an alternative implementation for those of us who choose to leave the CPU, even if not the screens, on 7/24. There is also a logical flaw. I have my entry in /etc/sysconfig/cron set: # At which time cron.daily should start. Default is 15 minutes after # booting the system. Example setting would be "14:00". # Due to the fact that cron script runs only every 15 minutes, # it will only run on xx:00, xx:15, xx:30, xx:45, not at the accurate # time you set. DAILY_TIME="04:00" But other people are going to turn their machine off when not in use and when they go to sleep, so that setting is of no use to them. They would have to set it while the machine is on ... ... AND THEY ARE USING IT ... Which is the situation Philip describes. And if this running of all the daily cron jobs one after another loads down the machine just when you need to clean up the end of the days work then TOUGH! I think this is a flawed design. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
There is also a logical flaw. ...
But other people are going to turn their machine off when not in use and when they go to sleep, so that setting is of no use to them. They would have to set it while the machine is on ...
... AND THEY ARE USING IT ...
Um...MS Windows (since, at least Win7 or Vista) has settings for dealing with this... Remember back in Win98(/XP?) people would complain about the indexing processes, so MS was 'responsive' to some level and added various options to operations that needed to be regularly done, like: _X_ Enable this task ___ Wake computer for this 'job' _X_ Start job only when PC is already on, but has been idle for ___ minutes. _X_ Pause this task if computer stops being idle. _X_ Do not run while on battery 10% Limit CPU usage of this program to 'xx%' of machine's capacity ... etc. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-11-21 03:03, Linda Walsh wrote:
_X_ Do not run while on battery
Some of the system cronjobs do this one. And some of the heavy jobs also stop if the machine is not iddle anymore. But it is not a generic setting, but specific coding. Maybe the use of cgroups would allow more systematic control. I know little of that. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 11/20/2014 09:33 PM, Carlos E. R. wrote:
On 2014-11-21 03:03, Linda Walsh wrote:
_X_ Do not run while on battery
Some of the system cronjobs do this one.
And some of the heavy jobs also stop if the machine is not iddle anymore. But it is not a generic setting, but specific coding.
Maybe the use of cgroups would allow more systematic control. I know little of that.
Yes, the potential is great, including forcing the cron.{daily,weekly...} tasks to use only one core of a multicore machine leaving the other cores available for normal use. That's not to say limiting cpu, memory and io, over and above what can be done with nice and ionice, isn't going to be useful. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-11-21 05:06, Anton Aylward wrote:
Yes, the potential is great, including forcing the cron.{daily,weekly...} tasks to use only one core of a multicore machine leaving the other cores available for normal use.
Interesting idea.
That's not to say limiting cpu, memory and io, over and above what can be done with nice and ionice, isn't going to be useful.
Absolutely. Another tool I use, rather than those, is "cpulimit". It forces the task not to use more than a percent of the cpu, no matter how free the cpu is or not. On a machine that is already running full time, it runs cooler. Takes longer, so what? And if you need the cpu for other primary tasks, you have it.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm...
I'll have to look at that link another day... humans have to sleep at regulars hours, something I tend to forget. But my body doesn't. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-11-21 05:06, Anton Aylward wrote:
Yes, the potential is great,
And was already being exploited before Srv-d came on the scene.
including forcing the
cron.{daily,weekly...} tasks to use only one core of a multicore machine leaving the other cores available for normal use.
Um,but those things have been around for years in various forms as well as on windows. I **mostly** use affinity on Windows, to keep all the system procs on 1 core competing with each other. I haven't really needed that as much on my linux box as it has more cores. I was also playing with devint affinity to see if I could get better perf if I received and processed net data on 1 core (not enough core to make for good test).
Another tool I use, rather than those, is "cpulimit". It forces the task not to use more than a percent of the cpu, no matter how free the cpu is or not. On a machine that is already running full time, it runs cooler. Takes longer, so what? And if you need the cpu for other primary tasks, you have it.[
----- That is one that will likely use more power. If you force a task to idle when nothing else needs the processor, then your process will start losing it's cache to other procs the longer it stays idle. That means the work will take longer and the cpu must remain in some ACTIVE state for a longer period (thus losing benefits of deeper sleep if the work was done sooner. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Nov 20, 2014 at 10:06:08AM -0300, Cristian Rodríguez wrote:
El 20/11/14 a las 00:06, John Andersen escribió:
Well, its 13.2 so I hope that is recent enough ;-)
I was more interested in the setting of time of he individual jobs that are scheduled for the system on a daily or hourly basis, etc.
You can do that with systemd timers functionality, though you can't just put these jobs there..you will have to:
a) Rewrite everything or..
b) Use something called systemd-cron which acts as a translator from crontabs to systemd units. This is a third party addon, as introducing this bridge between incompatible worlds was rejected for inclusion in systemd.
The imcompatable worlds between Linux and SystemD iFor 15 years cron has made an most excellent alarm clock, and controls a decent number of x25 boxes in the hours, reminds me of appointments, cleans my log files out and automates mirroring and rekicks a number of remote servers. It is good to know that systemD will now save me ... Ruben
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 22/11/2014 05:29, Ruben Safir a écrit :
iFor 15 years cron has made an most excellent alarm clock, and controls a decent number of x25 boxes in the hours, reminds me of appointments, cleans my log files out and automates mirroring and rekicks a number of remote servers.
I could make photos for 40 years with film, why should I use digital photo now? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/21/2014 11:29 PM, Ruben Safir wrote:
iFor 15 years cron has made an most excellent alarm clock, and controls a decent number of x25 boxes in the hours, reminds me of appointments, cleans my log files out and automates mirroring and rekicks a number of remote servers.
The issue, the start of this thread, has nothing to do with systemd being able to replicate exactly the way the present cron.{hourly,daily,weekly,monthly} works. The problem the OP had arose from using the basic old fashioned cron. The problem was that the thwe way this worked produced a BIG THUD at 5pm every day that rendered his system unusable. That's an emergent property of the way this facility was built on top of the old fashioned cron. Systemd had nothing to do with it. What John is complaining about, what I and others have commented on, is the way that the new fangled script on top of cron works has removed from our control the fine tuning of when key systems tasks are run. When I and others comment that this is more like the world of the Microsoft PC rather than the traditional *NIX world, I'm referring to the *NIX world of machines being 'always on' (even if their display is turned off, they are headless, whatever[1]) as opposed to the PC habit of turning on and off for short periods. The idea of such habits and practices common to the PC/Windows world being transferred and hence accommodated in the Linux world is rather scary! [1] I turn my display off at night and the things under my desk are headless. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/22/2014 03:04 AM, jdd wrote:
Le 22/11/2014 05:29, Ruben Safir a écrit :
iFor 15 years cron has made an most excellent alarm clock, and controls a decent number of x25 boxes in the hours, reminds me of appointments, cleans my log files out and automates mirroring and rekicks a number of remote servers.
I could make photos for 40 years with film, why should I use digital photo now?
Way to go, JDD! Recidivism Rules. Bring back your PDP-11s. Bring back your steam powered PDPD-11s. Bring back the coal mines to power the steam generators to power the PDP-11s. Bring back full employment for coal miners and cola miners sons. Bring back pneumoconiosis ('black ling disease') and 'London Fogs'. Global Warming? Talk to people in Buffalo about that. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 22/11/2014 13:09, Anton Aylward a écrit :
practices common to the PC/Windows world being transferred and hence accommodated in the Linux world is rather scary!
it's the case for desktops since ages... jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 22/11/2014 13:15, Anton Aylward a écrit :
On 11/22/2014 03:04 AM, jdd wrote:
I could make photos for 40 years with film, why should I use digital photo now?
Way to go, JDD! Recidivism Rules.
may be I missed the smiley :-) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-11-22 04:55, Linda Walsh wrote:
Another tool I use, rather than those, is "cpulimit". It forces the task not to use more than a percent of the cpu, no matter how free the cpu is or not. On a machine that is already running full time, it runs cooler. Takes longer, so what? And if you need the cpu for other primary tasks, you have it.[
That is one that will likely use more power.
If you mean watts, it is debatable, yes.
If you force a task to idle when nothing else needs the processor, then your process will start losing it's cache to other procs the longer it stays idle.
No, that is not the case. A process is limited to, say, 50% or 80% or 90% of the available cpu power, any figure you wish. The idea is that this intensive and long task never goes beyond that figure, but otherwise takes as much as it wants (till the limit), and never really idles, so its caches are there — unless those primary tasks are also intensive. It is curious that by choosing nice and a 90% limit, the desktop remains very responsive and fast, because there is always some free cycles for the jobs that watch for the user activity, instead of those processes competing for cycles. Caveats. Control is not smooth. It is not done directly by the kernel, but via a trick: the control process stopping and restarting the target task dunno how many times per second. The CLI can be confused and think it went into BG. On modern CPUs, you use less electricity by having the task run as fast as possible, then fully idling the cpu at the end, that by running it slowly. I doubt this, specially if the cpu runs at a lower clock, but there are apparently studies on this. I'm not sure about the fan and cabinet heat control, though. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On modern CPUs, you use less electricity by having the task run as fast as possible, then fully idling the cpu at the end, that by running it slowly. I doubt this, specially if the cpu runs at a lower clock, but there are apparently studies on this. I'm not sure about the fan and cabinet heat control, though.
Since I use my excess heat to heat my home about 8 months out of the year, it doesn't go to waste. I used to go through about 1.5 "cords" of wood ea/winter. If you want to bring in clock speed, you can adjust that with the cpu governor as well as the "cpupower" command -- restrict it to 100% of your lowest cpu-freq. That should keep the cache busy but use minimal extra power. That said, things are almost always a bit specific to a particular work load, but set the cpu and ionice to minimal (ionice -c3 nice -19 for the lowest jobs). Since my linux server has all my data, I have a another sched-task to bump-UP any "smb" processes running as me. I have more uses of ionice -c2 -nX (best effort;X:0-7) as well as using different cpunice (aka 'nice') values for different tasks. I.e. many of my background processes are resource controlled and tuned to my normal usage patterns. Generally I use the CFQ cpu scheduler with the default auto-grouping -- that was a HUGE improvement over earlier schedulers. I can run a kernel build with 'make -j' and usually have no effect on interactive tasks. Usually I go for "-j <#cpus*1.3>" for optimal balance between disks and cpu's. I check for changes to verify they actually help -- if not, I try to roll things back to defaults. A recent problem caused by Xd: random changes in the cgroup format -- with the more useful features being hidden away from the "/sys" interface. Haven't had time to deal with that yet. *sigh*.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Nov 22, 2014 at 09:04:23AM +0100, jdd wrote:
Le 22/11/2014 05:29, Ruben Safir a écrit :
iFor 15 years cron has made an most excellent alarm clock, and controls a decent number of x25 boxes in the hours, reminds me of appointments, cleans my log files out and automates mirroring and rekicks a number of remote servers.
I could make photos for 40 years with film, why should I use digital photo now?
That is a good point. It has nothing to do with MY Point, cron or the conversation... but as long as you keep making good points... they are worth reading. How do you feel about relief pitching in the major leagues? Good or Bad? Now, getting back to crontab. It works. It is effective. It is an essential part of the GNU and Unix tool chain. Any innovation of it, which has happened over the years, DEPENDS on it remaining INDEPENDENT. When it is aborbed by systemd, it is dead... innovation is dead ...and that is besides the problem that systemd is buggy, rushed and it sucks. Now I want to address film. Film is remarkable and it has a lot more information even on the cheapest crappiest photographs than any digital file. But my recent run in with the PNGLIB breakdown has put over 10 years of digital images at risk because of shitty decision by a developer on libpng who doesn't get a damn about my pictures or family, much like the systemd develoeprs for that matter. It was a real wakeup call and so I went out a purchased a good photo print. It is not nearly as good as a photograph, but I can't trust people like the deveopers of libpng or the developers of systemd with my family's heirlooms. They are RECKLESS and have no compasion. Ruben -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 22/11/2014 20:06, Ruben Safir a écrit :
On Sat, Nov 22, 2014 at 09:04:23AM +0100, jdd wrote:
I could make photos for 40 years with film, why should I use digital photo now?
sorry, I missed the smiley since I buy my first DSLR, I nver anymore used films, not even those I had already...
That is a good point. It has nothing to do with MY Point, cron or the conversation...
I want to state that things are changing, like it or not, and at some point it's necessary to jump in tha waggon (like it or not :-()
How do you feel about relief pitching in the major leagues? Good or Bad?
in France this is like alien ligue :-)
Now, getting back to crontab. It works. It is effective. It is an essential part of the GNU and Unix tool chain.
and it wont be anymore atr some moment (unknown to me), and?
Now I want to address film. Film is remarkable and it has a lot more information even on the cheapest crappiest photographs than any digital file.
do you really think so? we don't have the same meaning for "informations", but I wont discuss this anymore here :-( (not the place) But my recent run in with the PNGLIB breakdown ? I would like to understand that, but may be not in this thread :-( (hint: default windows 8 image format seems to be png, so I'm pretty confident about png life, even if I use jpg) thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/23/2014 03:49 AM, jdd wrote:
since I buy my first DSLR, I nver anymore used films, not even those I had already...
Ditto. Piles of "X" in my fridge that I'm probably never going to use. Expensive and very nice old Canon in the bottom of the cupboard with lots of great glass that isn't 'automatic' enough for the modern cameras. Its a con-game to make us spend, spend, spend! Continual obsolescence! -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-11-23 16:40, Anton Aylward wrote:
Its a con-game to make us spend, spend, spend!
I no longer spend on film, paper, chemicals, lamps, equipment, lab space, dark room. Only the camera is needed. Nor have I to wait to finish the roll and have it developed and printed. Sure, on the last years the processing could be done in an hour - after you finished the roll, blind. Nor do I need to scan the prints in order to send emails, compose documents in OO, or do some digital enhancing with gimp. And even cheap cameras are so smart now that they can take a night photo of a person, getting the dark background plus the person with flash, both correctly made. Not an easy trick on film, which I used, so I know how complicated it was to get it right on a single attempt (subjects don't like you taking five more photos, differently adjusted, making them wait for the flash to recharge on each). Or cameras that can process a dark scene and remove camera shake. And they fit inside a pocket! Thousands of photos! So no, I don't miss film that much. What I regret is the price of good cameras and having to learn new techniques. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (9)
-
Anton Aylward -
Carlos E. R. -
Cristian Rodríguez -
ellanios82 -
jdd -
John Andersen -
Linda Walsh -
Patrick Shanahan -
Ruben Safir