|
Your not Venetian - what do you know about canals?
Like here in NY we don't wear cowboy hat or bolo ties. So,
Keep to your designated by birth expertise[^].
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
|
Impressive video. What I found amazing wasn't the cratering but that Mars has the same wind sculpted features you'd see in a large snow field or really dry desert.
|
|
|
|
|
Having re-watched it with a critical eye, I think I can see how some people could argue it's fake, the rocks and craters 'don't look right' or the resolution of the cameras is too low. Think about it you can get jerky low res video from YouTube thats coming from a sever on the earth! How far we have come we can get low res video with a lag of minutes that appears like you tube from the late 90's! Compare that to the Apollo footage! Wow! said it once more than likely I'll say it again.
|
|
|
|
|
OriginalGriff wrote: And for a planet with an atmosphere (albeit a load thinner than Earth's) that's a lot of craters: old ones, new ones, weathered ones, fresh(ish) ones ... everywhere is craters until you get too close to see the big ones .
Yes, this is intriguing isn't it. It looks very much like the Moon in this respect.
I hypothesize that it's due to lack of biosphere[1]. No biological activity to help cover up features; only wind erosion and frost (and maybe occasional and brief water flows).
Footnote:-
1: Lack of substantial, current, biosphere, anyway. I still wouldn't be surprised if some bacteria and maybe algae were still there, somewhere.
|
|
|
|
|
HG Wells said something...
|
|
|
|
|
|
I really didn't see a proper forum for this question - logging begs toward philosophy and religion.The general forum has provided excellent feedback on bat files and glasses. So it's time to get serious. If there is a better place for this, don't post answers just point me and I'll relocate.
Logging. Application level. I've been in this business for a long time, and there does not seem to be a method to the madness. Most logging is reactive. Jeese, it stopped working guess I better monitor memory, etc. So logging is added after the fact. Well that helped - not. I'd like to hear from others what they just know they need to log. FWIW, I don't care about the application environment - web, server, desktop or embedded.
There is an article brewing... my opinion is that every application needs logging.
thanks all. 60 degrees in Atlanta today, nice breeze and sunny skies. Sorry Texas.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
A philosophy question then.
We have four main types of logging:
- Traffic logging. The boring standard old stuff.
- Error logging. Reactive by definition
- Process logging. How many times did X happen per time interval
- Health logging. Preemptive.
Our Health logging is the most interesting because it's broken into a few main areas (disc, database, file and cache server) and is all defined using a set of rules in a JSON file that can easily be updated.
We build rules to run a test against systems that could be in error to spot conditions that may lead to an error, or may indicate that something else isn't working which may in turn cause an error. For instance, is memory getting low? Are we seeing too many network outages? Our background process queue is starting to fill up, we're not seeing as many votes as we'd expect, our cache server seems to be a bit slower than we'd expect. Each of the rules is run every 5 minutes and then we build a page that has a big green tick or a big red X. If the X appears our monitoring guys let us know and we can dig in and see what's happening before things get out of control.
Our logging / monitoring is always (almost by definition) going to be reactive, but over time we've built up a great set of rules that enable us to head issues off at the pass.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Our logging / monitoring is always (almost by definition) going to be reactive, but over time we've built up a great set of rules that enable us to head issues off at the pass.
That seems to me to be the hallmark of a mature application that logs. After a certain point it goes from being totally reactive to somewhat preemptive.
Real programmers use butterflies
|
|
|
|
|
(5.) Security / bozo logging:
As in, "Who auto-generated those 500 purchase orders?" (That now have to be reversed).
True story; the new Accounting Manager seeing "what does this do?". The "action log" told the story.
(Interesting: CP changed my unbracketed 5 to a 1).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Gerry Schmitz wrote: Interesting: CP changed my unbracketed 5 to a 1
Ye - you have Markdown selected, so it gets a little ahead of itself sometimes)
But I do like your point: Auditing. Super important. Always nice to be able to point the finger.
cheers
Chris Maunder
|
|
|
|
|
I used worked to in automation systems that dealt with millions of dollars worth of product at a time - cassettes of wafers full of chips. We learned really, really fast that a production log was essential. We were often asked to explain why entire cassettes were scrapped and the answers boiled down to very poor training by the customer. Their operators somehow got into their head that if the slightest thing went wrong then click abort which effectively trashes all product in process - sometimes three or four cassettes at once. It had multi-level "are you really, really sure?" prompts but they did it anyway.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Have a meta story on that subject.
When Windows Server 2000 was new I found the setting for "Audit logging" and thought: "Cool, have to test that".
Not much later, the server is basically unresponsive.
Have never touched that setting since. 
|
|
|
|
|
I don't like logging which is why I don't instrument for it until i have to, or if i'm working on a system that I can't debug for whatever reason.
I don't like it because
A) it's yet another thing to manage. Who cleans up your log files, just for example?
B) it's more work and in most applications on a modern machine I've written them such that I can identify the problem with a little bit of tinkering in a debugger. So it just doesn't pay for itself the way i code, or at least it doesn't pay for itself to do so preemptively
C) This is mainly a complaint i have with my C++ apps for reasons, including reasons of not having much of a unified way to do reliable logging that's consistent from app to app, but there's just so much buy in for logging and then usually it means injecting those dependencies into every single part of your code, which means all your libraries you produce and such have a fixed dependency on a logging subsystem, which now you have to manage as well. And across all the libs you've built that use it. Unless of course, you're just basically doing dirty old printfs...
I should add the caveat that I do not do enterprise application development anymore. If there were ever a good case for logging, it's on large incredibly complicated applications running on disparate, possibly remote systems.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: enterprise application development anymore. If there were ever a good case for logging
ding ding ding ding!
you win.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
honey the codewitch wrote: If there were ever a good case for logging, it's on large incredibly complicated applications running on disparate, possibly remote systems
Exactly our use case, and the reason why we built our own system. It's based on TCP/IP sockets and each software component contains a small server. Our client application can connect to as many of these servers as you like. The servers send messages (printf() on steroids) and the client can send commands back to the servers. The client can save traces to a file, and can be set up for recording continuously over a long term. It's proven invaluable given that our product runs on multiple computers and each component is heavily multithreaded. The client application is our oldest piece of software still in continual development. It got its start in 2000, and gets a new release every now and then as we discover a need for a new feature (or I get bored and want something fun to work on for a change  ).
Software Zen: delete this;
|
|
|
|
|
Right on! and it's encouraging that I'm not actually getting ripped apart in the comments over my remarks.
This place is really heavy on business development, i think because that's what most development is, and logging is big business. 
I'm in the minority it seems, in that I don't do bizdev, at least not anymore. I write commercial software, but it's not b2b or ecom or anything like that.
Logging is useful for me in certain situations, but in a lot of them it just isn't.
Real programmers use butterflies
|
|
|
|
|
In my case, I have embedded systems all over the world. There is no way to attach a debugger.
In addition to having thousands of systems all over, toss in multiple versions of code and a varied mix of connected hardware, all running in different production environments, and we have a real opportunity for understanding what data is necessary to collect to allow us to figure out what is wrong.
I do like the idea of different flavors of logging. We do this now on one side the system, but on mine, I'm just dumping into a text file what I think is useful. I'm going to think about dividing it up.
As for managing the log files, we set a max side and roll across 3 of them.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
|
Thanks, I'll grab them now.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Last company, we logged everything; enter any method, its name and parameters logged.
I prefer mini-dumps.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
charlieg wrote: I'd like to hear from others what they just know they need to log.
I've always found a stack trace and minidump to be very useful. Combining it with a log only helps to find what the user was doing when the exception occured which might not be of interest.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: Combining it with a log only helps to find what the user was doing when the exception occured which might not be of interest.
This. I'm so glad you wrote this because it so succinctly describes what logging is for - tracking the user's movements through the app, rather than what the app is doing.
Now in my code on my jtagless embeddeds i have to log what the app is doing too, because i don't have a debugger, but generally - i'd say in most cases, you're right to bring this up.
If you're logging things other than the user's movement through the app you just might be using the wrong tool for the job.
Real programmers use butterflies
|
|
|
|
|
Yeah,
Situational awareness via telemetry is also important though. It helps developers learn what features are being used in your application (or operating system). By tracking the user movements through your application (or operating system) you can easily identify which features are not being used.
In the old days developers would add/design features and have no clue that absolutely nobody used it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
