Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rule of Silence (2006)

linfo.org

Post reply on HN
Print view View original

51–60 of 318 posts

Re: The Rule of Silence (2006)

#51

Post by vog »

kbart wrote: post #47

Having debugged Linux kernel and userspace programs extensively, I'd say this rule is golden. Typical user don't need logs, unless something is really f*cked up. On the other hand, if you are running production or development machine, you can enable as many log messages as you want as most of it can be turned on via /proc/sys/kernel/printk (kernel messages), program parameters or writing your own specific messages in…

> there are so many log messages, that it's hard to find a specific problem among them.

This is exactly my experience, too.

Some programs get this even worse: They spam you with lots of useless information, yet when something goes wrong, you don't get the information you need. Instead, you have to rerun it to increase the verbosity even more.

So ... if I have to rerun and having a hard time trying to reproduce the issue anyway, why did it spam me in the first place?

Re: The Rule of Silence (2006)

#52

Post by pherq »

setrofim_ wrote: post #18
zeveb wrote: post #13

Earlier quoted context omitted.

Note that I'm not arguing for structured binary data. Structured text (e.g. s-expressions, JSON, even the-extensible-structured-text-format-which-shall-not-be-named) can last just as long. Indeed, S-expressions have existed since the 1950s. There's no particular reason why /etc/passwd couldn't be: ((root nil 0 0 root /root /bin/bash) (daemon nil 1 1 daemon /usr/sbin /usr/sbin/nologin) …) There are any number of simil…

What would your example achieve? You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks. Though I do agree with your overarching point that some of the formats/outputs could do with a more consistent structure. Perhaps something like YAML would strike a good balance between structure a…

> What would your example achieve? You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks.

That particular example is fairly straightforward (at a simple level, passwd files aren't complex), but being able to express arbitrary nested structure would make various things a lot more straightforward. Line breaks and some sort of tab/colon/what have you work fine if everything has at most two levels of hierarchy, but it starts being painful after that.

Missing matched parens are a bit of a specious argument, since many of the random formats for files are fairly strict about what they parse, and the ones that matter (e.g. passwd, sudoers, crontab) are conventionally edited through tools that check the syntax before committing.

Re: The Rule of Silence (2006)

#53

Post by pif »

bjourne wrote: post #24

It's often a stupid rule. If you have a process that is stuck, you type "kill " to kill it. But kill doesn't tell you if the process was killed or not, so you have to double-check with "ps " to see if it is still alive. If it is, you try again with "kill -9 ". I suspect the reason is that for most signals, kill can't determine if the signal was acted upon or not. But for KILL and TERM it could wait a few milliseconds…

> But for KILL and TERM it could wait a few milliseconds...

It wouldn't make sense:

1) the TERM signal can be trapped by the process, and "kill" has no right to assume that the process is supposed to quit;

2) the KILL signal is managed by the kernel and it just works (if it doesn't, then your kernel is buggy and you have more serious problems); even if "ps" shows the process as still alive after a "kill -9", you can assume it'd dead process walking.

Re: The Rule of Silence (2006)

#54

Post by throw2016 »

I think using the word 'philosophy' is like antimarketing. People have a kneejerk reaction to the word as something unchanging and stuck in the past and it lends itself easily to negative connotations.

Take an example. Build small components that can be reused. Its like SOA way before SOA came into use and makes perfect sense. Now criticizing that is much more difficult and will require technical depth than just dimissive comments about 'unix philosophy'.

In this case this is the first I've heard of a 'philosophy' of silence and it is often not golden. From a technical perspective its important for users to get feedback and not generic unhelpful error messages or commands disappearing. Fortunately on Linux logging is usually quite good and most experienced users can pinpoint errors quite quickly but options like -v, --v, -vv, -vvv far from helping often increase technical load.

Re: The Rule of Silence (2006)

#56

Post by dangravell »

The Unix philosophy of small, modular processes feels right to me, as a user and a coder.

However the business and product developer in me wonders how I apply this to building more complex systems. Normally this involves building multiple functionalities. Does the philosophy say I shouldn't build "systems" that are complex and do multiple things? Or does it talk about how these should be implemented, as co-operating processes?

Re: The Rule of Silence (2006)

#57

Post by pif »

bjourne wrote: post #24

It's often a stupid rule. If you have a process that is stuck, you type "kill " to kill it. But kill doesn't tell you if the process was killed or not, so you have to double-check with "ps " to see if it is still alive. If it is, you try again with "kill -9 ". I suspect the reason is that for most signals, kill can't determine if the signal was acted upon or not. But for KILL and TERM it could wait a few milliseconds…

> It's often a stupid rule.

By the way, I haven't down-voted you, but I think I understand why others did. Before calling stupid a pillar of a (programming) philosophy with decades of useful outcomes, you should stop and ask yourself whether it's just a matter of taste on your side or, even more likely, of ignorance.

Re: The Rule of Silence (2006)

#58

Post by pif »

grabcocque wrote: post #20

May as well be called the rule of gratuitously hostile user experience.

It's clear you don't know what you are talking about.

- Contrary to popular belief, Unix is user friendly. It just happens to be very selective about who it decides to make friends with.

Re: The Rule of Silence (2006)

#59

Post by babuskov »

return0 wrote: post #45
vog wrote: post #26

Earlier quoted context omitted.

> Famous example: trying to exit vi To be fair, this has been fixed a long time ago. At least Vim (which is the Vi installed on most systems) shows the following message on startup: ~ VIM - Vi IMproved ~ ~ version 7.4.1829 ~ by Bram Moolenaar et al. ~ [...] ~ Vim is open source and freely distributable ~ ~ Help poor children in Uganda! ~ type :help iccf for information ~ ~ type :q to exit ~ type :help or for on-line…

to be fair thats not enough either. someone might accidentally have pressed 'a' , and now good luck understanding how to get out of it without having a crash course on vim

Yeah, whenever I run some program, I just press a random key like "a" to get started. ;)

Re: The Rule of Silence (2006)

#60

Post by edblarney »

dangravell wrote: post #56

The Unix philosophy of small, modular processes feels right to me, as a user and a coder. However the business and product developer in me wonders how I apply this to building more complex systems. Normally this involves building multiple functionalities. Does the philosophy say I shouldn't build "systems" that are complex and do multiple things? Or does it talk about how these should be implemented, as co-operating…

The 'do one small thing and do it well' philosophy is at least contentious in the general sense.

Reality: no unit exists outside the context of it's ecosystem.

Ergo, the API to that unit, and the degree to which it integrates with the other pieces is paramount.

The 'do one thing and do it well' ideal implies almost a kind of 'unit sovereignty' that in many cases does not exist.

In large, complex systems, 'units' can only view as parts of a greater whole.

'What they do' is almost less important than 'how well they fit'.

Post reply on HN