Ecco una descrizione di alcuni tratti comuni a molti nerd, in particolare agli informatici dediti al mondo unix/unix like, in cui io mi riconosco al 100%. Se sei una di quelle persone che a volte si lamentano delle mie lungaggini e pignolerie e/o scortesie apparenti nel risolvere problemi, leggilo bene, e forse mi capirai un po’ meglio:
Nine traits of the veteran Unix admin
By Paul Venezia
Created 2011-02-14 04:00AM
Veteran Unix admin trait No. 1: We don’t use sudo
Much like caps lock is cruise control for cool, sudo is a crutch for the timid. If we need to do something as root, we su to root, none of this sudo nonsense. In fact, for Unix-like operating systems that force sudo upon all users, the first thing we do is sudo su – and change the root password so that we can comfortably su – forever more. Using sudo exclusively is like bowling with only the inflatable bumpers in the gutters — it’s safer, but also causes you to not think through your actions fully.
Veteran Unix admin trait No. 2: We use vi, not emacs, and definitely not pico or nano
While we know that emacs is near and dear to the hearts of many Unix admins, it really is the Unix equivalent of Microsoft Word. Vi — and explicitly vim — is the true tool for veteran Unix geeks who need to get things done and not muck about with the extraneous nonsense that comes with emacs. Emacs has a built-in game of Tetris, for crying out loud.
I’ll grudgingly admit that the bells and whistles in vim such as code folding and syntax highlighting might be considered fluff, but at the end of the day, real Unix work blends extremely well with vi’s modal editing concepts. In addition, its svelte size and universal portability make it the One True Editor. Thanks Bill, thanks Bram.
Veteran Unix admin trait No. 3: We wield regular expressions like weapons
To the uninitiated, even the most innocuous regex looks like the result of nauseous keyboard. To us, however, it’s pure poetry. The power represented in the complexity of pcre (Perl Compatible Regular Expressions) cannot be matched by any other known tool. If you need to replace every third character in a 100,000-line file, except when it’s followed by the numeral 4, regular expressions aren’t just a tool for the job — they’re the only tool for the job. Those that shrink from learning regex do themselves and their colleagues a disservice on a daily basis. In just about every Unix shop of reasonable size, you’ll find one or two guys regex savants. These poor folks constantly get string snippets in their email accompanied by plaintive requests for a regex to parse them, usually followed by a promise of a round of drinks that never materializes.
Veteran Unix admin trait No. 4: We’re inherently lazy
When given a problem that appears to involve lots of manual, repetitive work, we old-school Unix types will always opt to write code to take care of it. This usually takes less time than the manual option, but not always. Regardless, we’d rather spend those minutes and hours constructing an effort that can be referenced or used later, rather than simply fixing the immediate problem. Usually, this comes back to us in spades when a few years later we encounter a similar problem and can yank a few hundred lines of Perl from a file in our home directory, solve the problem in a matter of minutes, and go back to analyzing other code for possible streamlining. Or playing Angry Birds.
Veteran Unix admin trait No. 5: We prefer elegant solutions
If there are several ways to fix a problem or achieve a goal, we’ll opt to spend more time developing a solution that encompasses the actual problem and preventing future issues than simply whipping out a Band-Aid. This is related to the fact that we loathe revisiting a problem we’ve already marked “solved” in our minds. We figure that if we can eliminate future problems now by thinking a few steps ahead, we’ll have less to do down the road. We’re usually right.
Veteran Unix admin trait No. 6: We generally assume the problem is with whomever is asking the question
To reach a certain level of Unix enlightenment is to be extremely confident in your foundational knowledge. It also means we never think that a problem exists until we can see it for ourselves. Telling a veteran Unix admin that a file “vanished” will get you a snort of derision. Prove to him that it really happened and he’ll dive into the problem tirelessly until a suitable, sensible cause and solution are found. Many think that this is a sign of hubris or arrogance. It definitely is — but we’ve earned it.
Veteran Unix admin trait No. 7: We have more in common with medical examiners than doctors
When dealing with a massive problem, we’ll spend far more time in the postmortem than the actual problem resolution. Unless the workload allows us absolutely no time to investigate, we need to know the absolute cause of the problem. There is no magic in the work of a hard-core Unix admin; every situation must stem from a logical point and be traceable along the proper lines. In short, there’s a reason for everything, and we’ll leave no stone unturned until we find it.
To us, it’s easy to stop the bleeding by HUPping a process or changing permissions on a file or directory to 777, but that’s not the half of it. Why did the process need to be restarted? That shouldn’t have been necessary, and we need to know why.
Veteran Unix admin trait No. 8: We know more about Windows than we’ll ever let on
Though we may not run Windows on our personal machines or appear to care a whit about Windows servers, we’re generally quite capable at diagnosing and fixing Windows problems. This is because we’ve had to deal with these problems when they bleed over into our territory. However, we do not like to acknowledge this fact, because most times Windows doesn’t subscribe to the same deeply logical foundations as Unix, and that bothers us. See traits No. 5 and 6 above.
Veteran Unix admin trait No. 9: Rebooting is almost never an option
Unix boxes don’t need reboots. Unless there’s absolutely no other option, we’ll spend hours fixing a problem with a running system than give it a reboot. Our thinking here is there’s no reason why a reboot should ever be necessary other than kernel or hardware changes, and a reboot is simply another temporary approach to fixing the problem. If the problem occurred once and was “fixed” by a reboot, it’ll happen again. We’d rather fix the problem than simply pull the plug and wait for the next time.
If some of these traits seem antisocial or difficult to understand from a lay perspective, that’s because they are. Where others may see intractable, overly difficult methods, we see enlightenment, born of years of learning, experience, and most of all, logic.
This story, “Nine traits of the veteran Unix admin,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news.
Some time ago i’ve discovered thanks to i can’t remember who/what something that’s looks like a very interesting voip phone: a CloudTC Glass 1000, something like a mix between a tablet and a voip phone.
As i need to develop a touch ip phone to be included in some home automation (domotic) systems i produce, i was interested in an android based phone as, you know, you can do any sort of things in an android device.
So, let’s no loose any more time, this is what i received from allnet italia ( distributor for cloudtc) is this:
The first thing that disappoint me is the lack of a cam on this device: what sense has an (apparently great) phone with an 8.9 inch touch display and android if you can’t make a videocall?
Anyway, also with the intention to eventually modify it on the hw side to add a cam, i try to understand how it work.
The PCB is composed by 2 different SoC connected by a local ip network over USB.
The first SoC is an ac494, a mips SoC with an internal DSP clocked at 125Mhz and a MIPS CPU clocked at 165Mhz commonly used for voip phones.
The second SoC is a TI omap-3530 ARM cortex-A8, a powerfull arm CPU of the same family used, for example, on pandaboard and similar boards. In the pictures you can also see ram and flashes for the two SoCs
NB: The post isn’t yet complete!
Today i received a Mikrotik Routerboard 493G, and i’m trying to use it with openwrt.
Basically using the same method of my previous post for rb450g it boot and a lot of things are working out of the box.
I’ve tryed also to install openwrt on nand, and it seem to work. So, what doesn’t work?
* Networking: the ethernet ports aren’t working.
* nand partially working: it seem that won’t save anything, you will loose any change after reboot.
* wireless: i have also a mikrotik minipci wifi card, lspci says it’s an ath9k, but it doesn’t seem to work ok.
Now, i’ll try to gettings things working.
For the networking, the rb493g isn’t so different from the rb450g. It uses the same switch chip, but it has two ar8316 instead of
one like in the rb450g.
As first step, i’ve tryed to make at least one of the two working applying this patch:
It seem to partially work: i can use 4 ports out of 9 on the board using this patch.
To be continued…