The disks in my home server have been acting up lately:
Two of them (which I bought at once a few years ago) deliver different results when I hash a file multiple times, another just randomly hangs sometimes for a few minutes.
The SATA and power cables seemed fine, replacing them had no effect on the problem.
So, why not check what wisdom S.M.A.R.T. has to offer?
root@holo:~# smartctl --all /dev/sdc
smartctl 5.43 2012-06-05 r3561 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family: Hitachi Deskstar 7K1000.C
Device Model: Hitachi HDS721010CLA332
##### snip #####
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Hm, looks like the disk is fine. So it's the SATA controller's fault after all... wait, what's that?
I am no authority on hard disks, and making sense of those numbers is hard.
But I can imagine what "Pre-fail" could mean.
Running a quick Internet search about this condition didn't really yield any definitive information.
It was suggested that this information shouldn't be taken at face value, since every manufacturer does their own thing.
Still, it's a little bothering.
Anyway, two new disks, 3TB each, will arive tomorrow or the day after. That should take care of the faulty reads - if not, I can probably scrap that motherboard or buy a PCIe SATA controller.
Moral of the story
Monitor all the things, so you can replace the disk while you can still read un-corrupted data from it.
Go redundant, so even a failing disk doesn't do any harm. I think I'll go with some sort of redundant ZFS pooling scheme.
If the summary says "Hey, no need to worry. Everything is fine, I got this.", ignore the summary and at least skim the details.
One of my jobs involves creating documents. >10MiB PDFs, or piles of dead
trees, if you will. Big documents with several contributors, providing revision
after revision of their part of the cake.
The process looks roughly like this:
The coordinator releases a structural guideline, with annotations indicating
which part belongs to which contributor. To a certain degree, contributors
may change the internal structure of their respective sections, while
bearing consistency with related sections belonging to other contributors in
mind.
Files: structure.docx
Contributors write the first revision of their sections and supply it to the
coordinator and other contributors for peer review.
At this point, the involved parties can inspect the compiled document for the
first time in its near-final form. Of course, some things aren't quite right.
So until they are, repeat steps 3-4.
Documents are distributed via e-mail and an online project management tool with
basic document management capabilities (you can upload and group files).
What's wrong?
A structural outline is provided (which is good), but there is no clear style directive.
The contributors format and style their contributions however
they want, which leads to varying styles when it comes to citations, language,
and structural decisions (Does this get its own caption? Should I write long
sentences or short ones?).
As a result, the editor spends a great amount of time on assimilating the
various styles from the contributions, so it all fits into a common document.
This involves restructuring, and even rewriting.
Maybe this doesn't deserve its own point, since it can be called the cause of
the above problem. It's Microsoft Word. It moves the contributors' focus
away from what they actually need to do.
Their job is to produce content. Not to format it in such a fancy way that's
guaranteed to break as soon as someone tries to incorporate it into the main
document.
It may become hard to trace a section back to its original author as soon as
the contributions get entangled in the main document. This can be a problem
if there are problems with the content, and the original author of this
topic would be the ideal person for the job to fix them.
The solution
What I'm about to propose is by no means the via regia for any attempt to
compile a document from various contributions, but it may be a nice approach for
technology-inclined people who find themselves in a situation such as mine, where
a multi-author document needs to be compiled.
Set up a source control system (SCS). Choose whatever suits your organisation's
religion. It doesn't matter if it's git, mercurial, svn, or anything else
centralized or decentralized, as long as it tracks changes and the identities
of those who made them. If less-technical people are involved, you might want
to prefer the SCS with a beginner-friendly GUI or write a small task-specific
tool.
In the SCS-tracked directory, create one folder for each contributor.
Set up a file hierarchy for a LaTeX document. Take care to split the parts of
the main document into many files. Store those files in the directory of the contributor responsible for creating the content for the section in question!_
Supply the contributors with SCS access and, if necessary, instructions on
how to get started with the SCS and LaTeX.
Pros and cons
Pro: The current state of the main document is available at any time, without
the need for manual integration.
Pro: Formatting is delegated entirely to the editor and the LaTeX compiler.
Contributors can focus on writing content.
Pro: SCS provides insight on which parts of the document were produced by who.
Also, there is a clear timeline of changes. The editor can switch back and
forth between several versions of a section without changing anything in
the rest of the document, with zero integration effort.
Con: The majority of the population has no experience with LaTeX, and, due to
the paradigm shift compared to WYSIWYG text editing, will probably have
a hard time getting used to it. The additional effort to train those people
might not outweigh the benefits of this solution.
Con: Source control systems, just like LaTeX, may be unknown and hard to
understand for many people.
Con: It's considerably hard to convince the ones in charge to choose such an
unconventional approach. Especially if a significant amount of money and a
tight schedule are involved, decision makers tend to stay conservative, even
in the face of a very promising alternative approach.
Conclusion and disclaimer
The presented solution enables a group of contributors to colaboratively create
a large document, while allowing writers to focus on content, and delegating
formatting to editors.
Compared to a classic docx sharing approach, the cost of integrating contributions
into the complete document is zero, as it is done automatically by checking out
of the SCS and running the LaTeX compiler. This allows for easier review of the
complete document by all parties involved.
I am by no means an expert on this matter. I just find myself in a situation
where using this approach would make my life a lot easier (in the roles mentioned
above, I'm an editor and a contributor), and save time and money.
This is a personal opinion, based on my experience, what I've heard from others,
and things I read on the Internet.
Recently, people on the Internet have been talking about (comparatively) cheap
27" monitors from South Korea with a glorious 2560x1440 resolution. Jeff Atwood
and Scott Wasson wrote about it, and
summarized their critiques fairly positively.
For something around €300, you can order a monitor like this
from a South Korean ebay vendor. Shipping and an international power adapter are
included. The monitors are of brands I've never heard of in the West, so I guess
they mainly supply Asian countries.
€300 is a fantastic deal, considering that 27" IPS screens with the same resolution
start at twice the price around here. So, after carefully studying online
reviews, I decided to take the risk and order one of those babies, since I was
contemplating to treat myself to some hardware as a reward for my recent graduation
anyways.
I ordered the same model Atwood and Wasson own. If I had been at home, the item
would have arrived just five days after placing the order, which is quite a
remarkable time. Not damages to the exterior, power light goes on. The moment of
truth.
Until now, I've been working with a single 24" 1920x1080 monitor, which was the
cheapest model available on Amazon when I bought it about four years ago. So
it's no surprise that the colors of the new monitor just explode in my face. I'm
pretty sure that I was grinning like a maniac for at least 10 minutes as a
reaction to those magical colors. Looks like money well spent.
It could have been perfect, but then again: No
The smaller issue is the screen surface. I was aware that I was ordering a
reflecting screen, but I didn't expect the reflections to be this annoying. I
can see my hands typing in a moderately lit room, which is somewhat distracting.
This can be dealt with, however: Either by purchasing some anti-reflection sheet,
or by getting used to it.
The big issue is that the screen came with two stuck pixels.
No dead pixels, fortunately. I managed to get rid of one using pixel massage,
but the other one still remains in the center region of the screen.
Considering the pain sending back the display would cause me (and the shipping costs),
I guess I can tolerate one stuck pixel. My usual window setup makes it practically
invisible anyway. It's only really annoying when watching movies.
Conclusion
It looks like I was just out of luck about that pixel business. As far as I recall,
the screens ordered by Atwood and Wasson were just fine, pixel-wise.
If you don't mind a reflecting screen, this monitor can be definitely recommended.
Customs in Austria only charge €42.10 - overall, you save more than €250 compared
to the cheapest model over here with equivalent specs.
My current internship at LIFEtool focuses on finding ways to utilize the Kinect as an input method for people with motoric disabilities. So far, I've been experimenting mainly with body poses and touching stuff (like a virtual button) as ways to express an intention.
When I'm talking about people with motoric disabilities, this usually means that they use a wheelchair and can only move parts of their body. Their degree of freedom of movement and the accuracy varies strongly from one to the other. While some can use both arms freely and accurately, others need lots of strength to move their hand for just a few centimeters.
I had never really had anything to to with people with disabilities before, so this was a journey into the great unknown. For the first milestone prototype, I tried to anticipate the needs of the software's audience as well as possible, based on second-hand information. I built a pretty accurate body pose recognition system, tested it thoroughly on myself and felt prepared for the first field test.
Facing reality
On the day of the first field test, my high expectations were shattered. We took the prototype to a local tech workshop for people with disabilities, set up the testing environment, and asked some of the workers to play a game I had hooked up to the body pose recognition system.
As it turns out, wheelchairs interfere significantly with the skeleton tracking software, which messed up the accuracy of the joint coordinates. The unstable movements of the testers increased the amount of error even more, making it even harder to detect body poses based on joint coordinates. The system did have a tolerance mechanism, which was calibrated individually for each user, but it couldn't handle deviations on this scale without increasing the number of falsely detected poses.
Why people with disabilities are great testers
Now imagine your usual test session with your average user. To find out their honest opinion about the product, you would probably have to resort to the information extraction methods of the Spanish Inquisition. Good testers are hard to get these days, everybody is far to nice and worked up about the developer's feelings.
My testers are better.
My testers are honest. If something's wrong, they tell you. If they like your product, they start negotiating the price. If the don't, say "This piece of crap doesn't work at all. I will never use it again.", and drive away. Doesn't matter, that the guy who spent the majority of his allocable time for the last month to make this thing is standing right there.
And instead of being pissed, I'm grateful. This ragingly disappointed user kept me on track and motivated, to improve the prototype, so he can use it too. In case you're wondering, we managed to convince him to give it another try at the next test session, and he was thrilled about how well it worked, compared to the first time around.
Moral of the story
Test with actual users.
Test early and often.
Encourage honest feedback.
People with disabilities are awesome testers!
It is not ethically responsible to outsource testing to the Aperture Science Computer-Aided Enrichment Center.
This post's soundtrack:
Jonathan Coulton - Still Alive (Portal Original Soundtrack)
Where I come from (central Europe) it is considered polite to turn down offers for things like a drink, seconds (as in food), or trivial favors, that wouldn't impose a significant amount of inconvenience upon the person offering it.
In some cases, of course, the refusal could be genuine. Those are not the cases I'm talking about. What I want to bring to your attention is the highly-desired ice cream you miss out on on a hot summer day, because you don't want to mooch off someone. I'm talking about the thirst you have to endure when you quickly stop by at someone's place and are offered a drink, which you refuse like it's the most natural thing in the universe.
Well, nobody would offer something if they weren't prepared to live with the consequences. You shouldn't feel bad for mooching off someone, as long as you return the favors from time to time. Say yes.
A different thing are offers of courtesy, where polite refusal is expected, and accepting the offer would even be considered rude. Since this is fake and evil, I personally recommend saying yes just to fight the metaphorical cancer of this practice.
If that was it for today's words of wisdom, I would gladly refund the two minutes of lifetime you wasted reading this, but it will (hopefully) be worth your while in a moment.
Don't stick it to the man
What comes now does certainly not apply to most people: Refusing little things as described above may be part of a much bigger problem, not just an issue of overly exercised politeness.
You surely remember a time in your past life when you were against most things. Even if you didn't realize it, you were against things as an end itself. You got over it, and now it's a thing of your past. Well, not necessarily.
As I said, this doesn't apply to everyone, and I'm not a certified psychologist, so don't quote me on the following. Based on totally unscientific observations, I daresay, while throwing an incriminating look at myself, that some people never fully leave this face.
The result of which is a remarkable resistance against doing what is necessary and required of you. This includes acting against your own interests, just so you can be against it.
Lots of words to describe a possible source for plain, old-fashioned procrastination -- the phenomenon, where any activity is prefered over dealing with the issues at hand. However, this might also be a cause for too frequently practiced "polite" refusal, as described above.
Moral of the story
Think twice before saying no.
When in doubt, say yes and deal with the consequences later.
Think carefully before accepting advice from strangers on the internet.
This post's soundtrack:
Darren Korb - In Case of Trouble (Bastion Original Soundtrack)
