I met a well known mountain climber recently who mentioned that he has been bringing laptops to Mt Everest for years now, but they all stop working above a certain altitude due to the air pressure drop (and, to a lesser extent, the temperature). Apparently it has been a big problem for the work they do for years now.
At altitude, the hard drives basically seize up, and the LCD displays develop a faint spiderweb pattern that makes the picture difficult to discern. Once they come back down, things start working normally again -- the hard drive starts spinning again and the LCD goes back to normal. Above a certain level though, the traditional laptop technology just doesn't work right.
He mentioned that they used to use original hard drive based iPods for data collection they do at the summits, but the flash based Nanos are much more reliable for their needs (not to mention smaller, lighter, and longer battery life...). Once the laptops start shipping with some kind of reliable solid state storage, they'll migrate to those also.
Did you realize that the world's most famous palace, it's grounds, and the community in front of it are laid out like an enormous happy-face stick figure? Take a look at that aerial photo, then go back and look at the Google view -- it's obvious once you look for it. And this all goes back to, what, 1500s and earlier?
It's striking how different this proposal sounds to how the Mac startup chime works.
Scoble dances around giving a full description, and it sounds like things are still being fleshed out, but the clear implication is that the plan here is to play some kind of music at either the login screen or (presumably if auto-login is turned on) when the current user gets to a working desktop. Implicitly, this is going to take a while, so they encouraging you to go for a walk and come back when the chime plays.
With a Mac, on the other hand, you get a polyphonic startup chime right when the machine is turned on. This fills a couple of functions, including welcoming the user to start working on the computer soon, and proving that the machine passed POST tests. Next the hardware is initialized, and system services start loading. Up until 10.3/Panther, the user would be presented with a series of frequently-vaguely-understood system services one by one as they loaded, but with 10.4/Tiger, the whole startup process was re-thought and replaced with launchd, which in turn made it possible to boot the system boot much faster (don't load unneeded services, delay non-critical ones until later, run as many of the others in parallel, etc) so that now you just have a sham progress bar as the system boots as fast as possible up to the login screen or desktop.
What is the better use of resources: figuring out how to make the system boot so fast that you don't have time to get that cup of coffee, or hiring 70s rockers to compose a melody to play once you've finished brewing another pot? Hmm.....
And before you say that Microsoft doesn't have as much control over the hardware, that's baloney. Be didn't have control over the hardware, and they had a hell of a lot less resources than Microsoft, and yet they still figured out how to get BeOS to cold boot to a functional desktop in 15 seconds or so. No OS shipping today that I'm aware of -- Windows, OSX, Linux, etc -- manages to do that as well as BeOS did a decade ago, and the hardware has only gotten better in that time. Why not? It's obviously doable. Figuring out how to get computers to do that again would be wonderful.
Oh, come on, name me one major hollywood movie with more realistic IT in it
The TV show "Alias" actually isn't that bad. The show is campy, sure, but in spite of being "high-tech" they mostly don't seem to indulge in much of the usual TV/movie pseudo-IT gobbleygook nonsense.
More to the point, whenever they have a shot of someone trying to break into a system, or get files off a system, etc, the commands they're typing to do so are generally credible. Sure, a display full of xterms isn't very exciting to watch, so they dress the xterms up with the usual MovieOS silliness of big fonts, translucent windows, etc. But look past that to what is actually being typed, and it's credible -- rsync files from bad guy's terminal to a USB thumb drive, ssh/scp back to the good guys, etc.
Compare & contrast with, say, "CSI: Miami", where the IT forensics nerd spouts off nonsense that half-correctly over-explains at a third grade level how he's trying to catch the bad guy based on log files on the laptop left at the crime scene, followed by screenshots, in full MovieOS glory, that don't even have any relation to what the actor was babbling about. And to top things off, they then follow up by noticing some possibly useful detail in an unfocused section of a photo found at the scene, so the boss says "enhance that" and presto-chango, you're looking at a perfectly focused, zoomed-in image of the perp and the murder weapon. I can't say how realistic the show is with other branches of forensics, but anywhere they get a computer involved, it's completely off-the-wall.
And likewise with the other CSI shows, or Law & Order, or any other modern cop show. But "CSI: Miami" seems particularly awful here.
"Alias", on the other hand, is at least accurate enough to not be distracting to someone comfortable with computers, and even more specifically, the Unix shell. That, I think, is as much as anyone can reasonably expect in pop fiction entertainment.
Yeah. That's the One True Path to a Rewarding IT Career.
On one hand, you can make your job seem like "magic", so that every time you do some stupid trivial fix for someone, it's mysterious and inaccessible. This is great, because it makes you seem like a miracle worker, but on the inside it gnaws away at your soul having to do the same monotonous grunt work all the time. Plus, if they ever catch on that these fixes are trivial, you've just tricked your way out of a job.
On the other hand, you can make plain what you're doing, so that every time you do some stupid trivial fix for someone, they can learn from you and fix it themselves next time. This is great, because it has the potential to free you up to work on more interesting projects in the long run, but it does run the risk that you'll seem less like a miracle worker. But, if they catch on how to do these trivial fixes for themselves, you've just tricked and taught your way into a promotion.
"Teach a man to fish, he'll eat for a day. Teach him how to fish and he'll eat for life."
The last thing we need is a "mystery of how IT performs its functions". What we need is transparency, and a way to empower people to solve their own problems so that we can focus on the truly difficult aspects of the job.
I've used VNC-like programs to help users fix things at their desk while I was at mine. It almost always went more smoothly if I either had them on the phone while controlling their terminal, or if I left the terminal interactive and left open a chat program (IRC, AIM, iChat, even just leaving open a text editor where I could type messages and they could respond) so they could see what I was doing, I could explain why, they could give feedback to help me solve the problem more quickly, and I could show them how I resolved the problem so that they could fix it themselves next time. In 9 times out of 10, if the problem came up again, they didn't need my help or my time to set things right again.
This curtain mode seems like a cute feature, but to me it seems best reserved for situations where the users can't be allowed to see what you're doing -- you have to enter or view admin passwords, you have to access systems that the users shouldn't see, etc.
You have to read the article to put the quote in context. The first paragraph, under a photo of a man facing a robot, reads as follows:
HER name is MARIE, and her impressive set of skills comes in handy in a nursing home. MARIE can walk around under her own power. She can distinguish among similar-looking objects, such as different bottles of medicine, and has a delicate enough touch to work with frail patients. MARIE can interpret a range of facial expressions and gestures, and respond in ways that suggest compassion. Although her language skills are not ideal, she can recognise speech and respond clearly. Above all, she is inexpensive . Unfortunately for MARIE, however, she has one glaring trait that makes it hard for Japanese patients to accept her: she is a flesh-and-blood human being from the Philippines. If only she were a robot instead.
Later on, the last paragraph, partly quoted in the Slashdot writeup, is:
What seems to set Japan apart from other countries is that few Japanese are all that worried about the effects that hordes of robots might have on its citizens. Nobody seems prepared to ask awkward questions about how it might turn out. If this bold social experiment produces lots of isolated people, there will of course be an outlet for their loneliness: they can confide in their robot pets and partners. Only in Japan could this be thought less risky than having a compassionate Filipina drop by for a chat.
As with many other things in life, it makes more sense in context. Here, the journalist is pulling the common writer's trick of using a catchy side anecdote as a framing device for a broader piece, using it to hint at how the topic being discussed -- the embrace of robot technology in Japan -- exists in a broader context of immigration, xenophobia, technophilia, and social environment.
If this is how Yahoo sees it, they're missing the point. Yahoo (and other web-portals) can use Social Networks to learn more about their users. For instance, a certain social circle may all be members of a bowling league, so maybe show bowling ball advertisers to people that have a direct connection with the bowling league circle. The connection I see is more in delivering more appropriate content to users, not saving money on search.
More important to a huge business such as Yahoo is how social search could bring new ways to cash in. Search engine firms make money through advertising, and in the short run, a tighter focus increases the likelihood of being able to charge higher prices for ads. In the long run, social groups might emerge inside the search engine - for example, a group of doctors in Hong Kong who share their bookmarks - who could be specifically targeted by advertising campaigns.
They get it. Or at least, the Guardian's reporter thinks they get it.
I'm assuming that the through-the-window models won't help you, but one of the portable ones might. To pick one at random, consider this portable A/C unit. The advantage of something like this, as opposed to the window fans that some others have suggested, is that it should come with an exhaust hose that you can channel to either the furnace's exhaust pipes, or to some other appropriate outlet elsewhere in your home. Something like that ought do do exactly what you need here.
It's very difficult to see how this could be implemented without undermining the entire moderation system. If editing were implemented, posts could be edited after they are moderated. While I have made my own share of grammatical, spelling, and punctuation mistakes, I see the need to fix posts in virtual stone for the moderation system to have any effectiveness at all.
Precisely. I can't think of any way that being able to edit posts after the fact would do anything less than completely ruin moderation.
The only solution I can think of is to allow people to either [a] append a change log / footnote to their posts, so that they could append thoughts to the intact original material, or [b] come up with a way to embed some kind of revision control system, so that you can make edits without amending, but visitors would be able to see how a post has evolved over time, and will be able to see what the moderation level was at with different iterations of the comment, and moderators could attach their revisions to specific point revisions.
The first option is much simpler, but not as elegant -- at least in terms of having tacked-on footnotes to revised comments. On the other hand, the second option seems like it would be very complex both to implement and for users to learn how to work with. I'm not sure that the complexity would be worth it, because it raises all kinds of edge cases -- should mod points for revised comments get invalidated, or pro-rated, or left alone?
Obviously, things are broken now, but allowing comment revisions seems like it could be a cure worse than the original disease...
In real life, how do programmers handle this situation?
You deal with it the same way anyone else with a job does: you learn to set, and meet, proper priorities.
An employee's job is to satisfy your manager's expectations that you are fulfilling your duty within the organization. This is true for anyone with a job, no matter what that job might be -- programmer, sysadmin, manager, garbage collector, whatever. It's true for anyone with a boss -- and pretty much everyone has a boss, whether it's a manager, a VP, a board of directors, the voting public, whatever.
According to you, your manager expects you to, quote, "that stresses correctness in programming first, amount of time needed second, features third". That's it then. That's your job. Period. If your manager is doing his job, then that's all you should need to worry about.
Your manager, by contrast, is responsible for fulfilling the expectations of upper management, namely, in "stressing features and amount of time needed first and correctness of programming a distant second". In practice, that means that he has to walk the balance between doing things right by his staff -- code correctness, then time constraints, then feature completeness -- and doing things right by his bosses -- features & time, then correctness. His job is to allocate staffing resources so that his team is doing things properly and at the same time keeping upper management happy.
The concerns of staff two levels up the chain of management aren't your problem; they need to be steering the direction of the business, and counting on the people working under them to be able to deliver. Likewise, the constraints that you need to be working within -- doing your job right first, and meeting time & feature needs second -- should not be the concern of the upper management; they have broader things they need to be focusing on.
Now, I realize that this is kind of idealized, and not all companies provide an environment where this is possible. Some companies are led by people that want to be very hands on with what their staff are doing, and sometimes that can even be a good thing. Other companies want to break down barriers between layers of management and staff, and that can also be a good thing. But having too many cooks in the kitchen, to rob a phrase, is rarely a good thing. If your company is big enough to have multiple layers of management, and they trusted your enough to give you a job, then they need to trust you to do that job, and they need to trust your manager to set your working priorities, and they need to focus their own efforts on steering the company itself so that you have something worth working on and the long term prospects of the company are assured.
And all that said, the one theme common to all of these different job functions is that everyone has to be able to understand and set priorities. In these days of relentless cost cutting and ever-increasing productivity, most people have more job responsibilities today than people did a couple of decades ago. The people that keep their jobs and keep getting promoted are the ones that figure out how to doing their immediate job right (so that it makes their direct manager happy) and making their manager's job easy (so that it makes the upper level manager happy).
And part of this means figuring out how to manage your time, what to focus your efforts on, and what parts of your job can be safely ignored. (And yes, implicitly, that means that some people won't be happy; you have to learn to live with this, unfortunately.) If banging out a sloppy version of your code gets something to your managers in a third the time that the "correct" version would have taken, then sometimes that's the compromise you have to make. But if you can make the case that spending the extra time to do it "right" will have benefits that offset the lost time & functionality -- for example, it can make future versions faster to produce
But what about the magazine publisher? What does she have to sell? What's she going to do now that she doesn't have stacks of glossy paper that people are going to want to hand over wads of greenies to acquire? Well, it all depends on what sort of business you think she's in. Lots of people are not in the business you think they're in. Xerox, for instance, is in the business of selling toner cartridges. All that mucking about they do developing high-tech copying and printing machines is just creating a commodity market in toner cartridges, which is where their profit lies. Television companies are not in the business of delivering television programs to their audience, they're in the business of delivering audiences to their advertisers. (This is why the BBC has such a schizophrenic time - it's actually in a different business from all its competitors). And magazines are very similar: each actual sale across the newsagent's counter is partly an attempt to defray the ludicrous cost of manufacturing the damn thing but is also, more significantly, a very solid datum point. The full data set represents the size of the audience the publisher can deliver to its advertisers.
Now I regard magazine advertising as a big problem. I really hate it. It overwhelms the copy text, which is usually reduced to a dull, grey little stream trickling its way through enormous glaring billboard-like pages all of which are clamoring to draw your attention to stuff you don't want; and the first thing you have to do when you buy a new magazine is shake it over a bin in order to shed all the coupons, sachets, packets, CDs and free labrador puppies which make them as fat an unwieldy as a grandmother's scrapbook. And then, when you are interested in buying something, you can't find any information about it because it was in last month's issue which you've now thrown away. I bought a new camera last month, and bought loads of camera magazines just to find ads and reviews for the models I was interested in. So I resent about 99% of the advertising I see, but occasionally I want it enough to actually buy the stuff. There's a major mismatch - something is ripe to fall out of the model.
If you browse around an online magazine (HotWired, for instance, springs unbidden to mind) you will find a few discreet little sponsor icons here and there which you choose to click on. You only get to see the proper ad if you're actually interested in it, and that ad will then lead you directly towards solid, helpful information about the product. It is of course much more valuable for advertisers to reach one interested potential customer than it is to irritate the hell out of ninety-nine others. Furthermore, the advertiser gets astonishingly precise feedback. They will know exactly how many people have chosen to look at their ad and for how long, with the result that an unwelcome ad for something no one's interested in will quickly wither away, whereas one which catches people's attention will thrive. The advertisers pay the magazine for the opportunity to put links to their ads on popular pages of the magazine and - well, you see the way it works. It is, I am told by people with seriously raised eyebrows, astonishingly effective. The thing which drops out of the problem is the notion that advertising need be irritating and intrusive.
He was being a bit optimistic, perhaps, but he's basically summarized the way things stand, or that they seem to be heading. And this was first printed in the original UK issue of Wired magazine, so that was what, a decade ago? The whole essay, What have we got to lose?, is fascinating stuff. Go read it if you haven't come across it before -- you'll be glad you did.
So you're saying that, with the magic of advanced rendering technology [only for Windows, yes?]
No. Sub-pixel antialiasing is also done by Xfree's font engines.
But then you're stuck using XFree:-)
Anyway the point wasn't to be a troll about it -- and in hindsight, I apologize if I came across that way. I'm just pointing out that while subtle tricks like subpixel rendering can do a good job at making the most of existing display technologies, even with their help, you're still getting a small fraction of the resolution available to even the cheapest of printers -- and those printers can often go much sharper if you want them to.
In order to get anywhere near the quality of print, display technologies need to either get radically more clever, or have to be superceded by something much finer grained. The way things are now, and have been for the past decade or more, display resolutions are an order of magnitude coarser than print ones, and on the whole, even things like TFT and subpixel rendering have not done enough to close the gap.
<half-facetious>
Of course, the obvious problem there is that they'd be stuck in Utah.
</half-facetious>
I'm sure Utah is a lovely place with lovely people, but I'm also pretty sure that it's a drastically different culture -- teetotalling button-down rural red-state Mormon on one side, drunken easy-going urbane blue-city Catholic on the other. That's stereotyping a bit, for which I apologize to both sides, but I think there's something to it -- I'm just not sure how well the hosts or the guests will get along together.
More importantly -- far more importantly -- a lot of these people don't want to be that far from home. Otis Air Force Base on Cape Cod was ready to take on 2000 refugees up until today, but now they're saying that few if any are actually going to show up. The main reason is simply that most people don't want to be that far from friends, family, or home -- even if that literal or figurative home isn't something they can ever go back to. Moving to Massachusetts, even if only for a few months, could feel like an admission that they can never go back to their homes, their belongings, and their memories, ever again.
If the long-term situation in New Orleans really is as bad as it seems to be, then I'm sure it's inevitable that there will be an exodus of people away from the city and from the region. But that's a painful step to take, and it may take a while before a lot of the people affected will be able to come to terms with this change. The collective trauma on the American psyche could prove to be far more painful from Katrina than it ever was from 9/11 -- then, we had an event that hurt a few thousand people in a few eastern locations, but this, in addition to killing at least as many people, looks ready to scatter hundreds of thousands of shell-shocked people all over the country. It could take decades to recover from this, if we ever do.
still, the best monitor available right now can do 133 DPI, if I'm up to date.
With subpixel anti-aliasing (i.e. ClearType et al) on a TFT display you practically get three times the resolution horizontally (you still need 3 adjacent subpixels per black dot, but it can be positioned more accurately), which helps quite a bit...
Wait, let me check my math here.
So you're saying that, with the magic of advanced rendering technology [only for Windows, yes?] on a high-end & presumably expensive display, you can ideally get... 133 x 3 = 399 or... 399 / 1200 = 0.3325... So, about a third as good as you can do with a hundred dollar printer and a penny piece of paper ? Hm...
Somehow, this doesn't exactly disprove the assertion that print quaility is still far better than anything a consumer computer can do on screen today, or in the foreseeable future.
"I work for a Fortune 500 Company as a Unix sysadmin and at any given time I may be working with 10 different project teams, each with their own milestones, tasks/to-dos, notes and reportable status. I'm constantly losing track of tasks that I need to do, notes I've taken and status reports that I've written. I've tried paper solutions, PDAs, Microsoft Project and groupware type stuff and nothing really seems designed to allow me to track mulitple project with mulitple tasks and to-dos as well as keep up with the status and notes that I generate from each of these tasks. How do you keep it all straight?"
I for one find a lot to like about RT, which is why I currently use it at home for tracking regular household chores just as I used it at my last couple of jobs for tracking all the little projects I was involved with. One feature that may appeal to you is that it's very easy to set up queues for different problem areas. If you have 10 project teams to manage, you can set up one (or more) queues for each of them, and people using the system can be set up to have access just to their own queue / project or to multiple queues / projects. People can create individual tickets for individual tasks / to-dos, and tickets can be linked ("refers-to", "parent", "child", etc), so you can set up arbitrarily complex dependency graphs among a set of tickets -- one ticket might be the umbrella for a project, and any number of other tickets can be linked under it as children or grandchildren or... whatever you like. And, of course, it's possible to add notes to these tickets either via going to your RT server's web site or via email messages to the RT system.
RT is all written in Perl and available under the GPL, and it'll run anywhere that Apache and mod_perl will run (Linux, Solaris, Windows, OSX, etc). Because it's so open, there's a lot of contributed add-ons available for it, as well as a pretty good collaborative documentation Wiki for the system. It can, admittedly, be a bear to install -- it depends on a lot of CPAN modules, so getting them all installed & configured can take a while if you're not lucky enough to be on a platform with a good package management system -- but there are installation guides for most major platforms, so you should be able to find a suitable one to start from.
Now, all that said, some of the other commenters noted that for the truly disorganized, no tool is going to get you past your own habits. Certainly, that's true, and coming up with a system for keeping yourself organized is tremendously important. In my case though, I have found RT to be a very useful organizing tool for my own needs, both at work and at home. It is, admittedly, a pretty complex piece of software, with a large number of nooks & crannies to learn about. But for starters, you don't need to know about any of that. Just being able to install it and start using it is all you need for now. If you need to, turn to the maili
Or is it when the Debian people say "stable", they mean a stable feature set and not necessarily stable security-wise?
I think that's precisely it.
I just left a job where all the Linux machines were running Debian Stable [Woody], unless there was a specific requirement for something else (e.g. a commercial application that wouldn't run reliably on anything but RHEL).
Everything was buggy as hell, but the admins were okay with this, because it was "stable". Desktop applications had thorougly well documented bugs or feature omissions that had been corrected upstream years ago, but if it wasn't available in stable (or maybe in backports.org, then an upgrade was strictly out of the question.
Therefore, I was constantly explaining to new people why CUPS crashed all the time, or why getting Gaim to connect to the Jabber server was such a convoluted process, or why we couldn't run Thunderbird or Firefox because the standard builds required a newer version of libc than what was locally available. Etc. Ad nauseam.
The logic for Debian stable comes really close to making sense, without ever quite working. You should be able to install the current Debian stable on a system, deploy it, and aside from occasional security patches, it'll always maintain the same state it was in the day you deployed it.... warts and all. And that's the catch -- there's lots of grimy old warts in a lot of the packages that had upstream fixes months or even years ago, but none of this is available to you unless you're willing to [a] build your own packages (and forego the wonder that is apt-get), or [b] upgrade to Testing or Unstable (and abandon the promise of stability & consistency, which isn't without merit).
Debian Stable is a great idea. It's disappointing that the reality of living with Debian doesn't live up to the naive promise of that idea. I can see where it's just the thing for a server that you want to set up and then ignore for a nice, long, mostly reliable decade, but for anything that you plan to put on your desk and have to cope with from day to day, it's just painful to live with.
I hadn't seen that, but it sounds like it wouldn't help. On a network of maybe fifty desktops and fifty servers, I can think of two XP machines, both of which are just there for QA work.
Now if it worked on Windows 2000, that would be something, and if it could wake up to run Adaware / Spybot / AV scans it would be something, and if it could do all of this remotely it would be something, and if it could manage responding to SNMP queries it would be something. And if it worked on OSX or Debian, then it would be something.
But it doesn't sound like it does any of that, or at least it doesn't without a good bit of manual tweaking. Hrm...
To be honest, no, not least because we have such a mix of hardware & software (a pretty even split among Debian Stable [Woody], Windows 2000, OSX 10.3/Panther, plus some oddball Windows XP, RedHat, and Solaris machines).
Would these things work across such a mix? I was assuming that it would be too much trouble to bother with, but maybe I'm wrong...
The limited testing of done -- say, trying to ping or ssh to a sleeping Mac that had been configured to "wake on network administrator access" -- has never gone well. If you can get a connection at all, it's only after waiting a minute or two for the machine to spin back to life, during which time the attempt to ssh in had usually timed out. I suppose that a bit of tweaking could get it to work, but that's just one target, and there's a whole bunch of them here to be dealt with...
At my job, we have all the servers & workstations configured to run 24/7, for several reasons.
On each computer, scheduled jobs (cronjobs on Linux & OSX, scheduled tasks on Windows) do things like backups, updates, antivirus & antispyware scans, etc. Making these things happen automatically and outside of business hours makes life much easier for the people that have to maintain all these systems (i.e. me). The main downside is that occasionally an operating system will force an unattended, unprompted reboot, causing the owner of that workstation to lose work. This is annoying, but we warn people in advance that it could happen, and they need to save their work before going home; the alternative -- manually finding out about & doing these updates machine by machine -- just isn't tenable.
The other benefit though is that we have SNMP monitoring of all hosts throughout the day. If a machine is having a hardware problem -- say, the printer is running out of toner, or someone's hard drive is filling up -- we get alert emails about it so that the problem can be fixed. This also allows us to know what machines are down at any given time, and have a reasonably small window indicating when it went down and when it came back up; this can help narrow down time frames for events like office power outages or, should it happen, the theft of a workstation.
I suppose we could get some of these benefis while also providing nightly downtime, but the benefits of having continual monitoring & maintenance are strong enough that there hasn't been a lot of call for it -- and when someone brings the idea up, the proposal usually gets shot down by the people managing the network.
If it were possible to bring this equipment into some kind of standby mode where it was still possible to do basic network tests (continually pingable, occasionally query for things like disc space, once-nightly wake up for updates & virus/spyware scans, etc) then maybe the idea would fly, but as things are now, there doesn't seem to be a good way to get these benefits other than by just leaving everything on all the time.
If nothing else, at least the monitors get turned off when they go idle...
I'll believe it......when I see multiple peer-reviewed articles reporting that others have been able to duplicate this experiment.:P
From the article:
This experiment has been repeated successfully and other scientists have reviewed the results: it looks like the real thing this time.
*ahem*
From the comment:
I'll believe it......when I see multiple peer-reviewed articles reporting that others have been able to duplicate this experiment.:P
In other words, an article in the Christian Science Monitor -- a fine newspaper, but not a scientific journal by any stretch -- in which the reporter casually asserts without citation that "other scientists" have "reviewed" the results, does not an independent confirmation make.
You can't just wave your hands and say "oh yeah, others have repeated it, others have reviewed it, we're done here." Who are these others? What exactly did they find, and how closely did everything match the original inputs & outputs? What kind of "review" did they do? We're still just dealing with anecdotes and hearsay, not scientific analysis.
What the grandparent poster implicitly asked for, reasonably, was [presumably refereed] articles in [presumably credible] scientific journals documented that other [presumably non-pseudo-science] researchers had taken the procedure described here, replicated the experimental apparatus, conducted their own trial of the experiment, and then verified that the results they obtained were in agreement with the ones predicted by the original researchers. If all that happens, then, and only then, are we getting somewhere.
Until then, this doesn't sound like much more than yet another cold fusion pipe dream.
RT runs great on Linux, FreeBSD, Solaris, Mac OS X and most other flavors of Unix. End users have contributed a port to Windows 2000 and Windows XP.
RT stores all its data inside an SQL database, so you can use Crystal Reports and similar tools to generate precise reports. Right now, you can deploy on MySQL 4, PostgreSQL 7.3 or Oracle 9i. Best Practical is working to bring support for Sybase and Informix to RT as well.
RT uses Apache's mod_perl interpreter or the FastCGI protocol, so you get blazing fast performance no matter what web server you choose.
That said, RT is a fantastic tool. I've used it at the last two jobs I've worked at, and if it's not there next time I switch jobs, I expect to introduce it. It can be a bit fiddly to get installed, as it depends on a couple of dozen CPAN modules, but the Wiki documentations'sgeneric and specific installation guides try to make this as painless as possible, and if you get stuck there's always the mailing lists and paid support. And once RT is up and running, it's stable, versatile, flexible, adaptable, and just all around a great tool for managing a collection of on-going tasks.
If it's good enough for NASA, Merrill Lynch, DynDNS, Perl (it's the bug tracker for the Perl language), and others, then chances are it's probably good enough for you too.:-)
Slashdot Mirror
I met a well known mountain climber recently who mentioned that he has been bringing laptops to Mt Everest for years now, but they all stop working above a certain altitude due to the air pressure drop (and, to a lesser extent, the temperature). Apparently it has been a big problem for the work they do for years now.
At altitude, the hard drives basically seize up, and the LCD displays develop a faint spiderweb pattern that makes the picture difficult to discern. Once they come back down, things start working normally again -- the hard drive starts spinning again and the LCD goes back to normal. Above a certain level though, the traditional laptop technology just doesn't work right.
He mentioned that they used to use original hard drive based iPods for data collection they do at the summits, but the flash based Nanos are much more reliable for their needs (not to mention smaller, lighter, and longer battery life...). Once the laptops start shipping with some kind of reliable solid state storage, they'll migrate to those also.
One of my favorites is Versailles. Yes, that Versailles.
Did you realize that the world's most famous palace, it's grounds, and the community in front of it are laid out like an enormous happy-face stick figure? Take a look at that aerial photo, then go back and look at the Google view -- it's obvious once you look for it. And this all goes back to, what, 1500s and earlier?
It almost makes you think that the French first sent people up in hot-air balloons just so that they'd get a chance to see the joke that architects & urban planners had set up centuries earlier...
:-)
It's striking how different this proposal sounds to how the Mac startup chime works.
Scoble dances around giving a full description, and it sounds like things are still being fleshed out, but the clear implication is that the plan here is to play some kind of music at either the login screen or (presumably if auto-login is turned on) when the current user gets to a working desktop. Implicitly, this is going to take a while, so they encouraging you to go for a walk and come back when the chime plays.
With a Mac, on the other hand, you get a polyphonic startup chime right when the machine is turned on. This fills a couple of functions, including welcoming the user to start working on the computer soon, and proving that the machine passed POST tests. Next the hardware is initialized, and system services start loading. Up until 10.3/Panther, the user would be presented with a series of frequently-vaguely-understood system services one by one as they loaded, but with 10.4/Tiger, the whole startup process was re-thought and replaced with launchd , which in turn made it possible to boot the system boot much faster (don't load unneeded services, delay non-critical ones until later, run as many of the others in parallel, etc) so that now you just have a sham progress bar as the system boots as fast as possible up to the login screen or desktop.
What is the better use of resources: figuring out how to make the system boot so fast that you don't have time to get that cup of coffee, or hiring 70s rockers to compose a melody to play once you've finished brewing another pot? Hmm.....
And before you say that Microsoft doesn't have as much control over the hardware, that's baloney. Be didn't have control over the hardware, and they had a hell of a lot less resources than Microsoft, and yet they still figured out how to get BeOS to cold boot to a functional desktop in 15 seconds or so. No OS shipping today that I'm aware of -- Windows, OSX, Linux, etc -- manages to do that as well as BeOS did a decade ago, and the hardware has only gotten better in that time. Why not? It's obviously doable. Figuring out how to get computers to do that again would be wonderful.
Actually, "dwarf planet" is considered rude.
It prefers to be called a "little planet".
(And besides, if Pluto is going to be the dwarf planet, which planet do the elves get? Or the hobbits? Won't someone think of the hobbits?)
The TV show "Alias" actually isn't that bad. The show is campy, sure, but in spite of being "high-tech" they mostly don't seem to indulge in much of the usual TV/movie pseudo-IT gobbleygook nonsense.
More to the point, whenever they have a shot of someone trying to break into a system, or get files off a system, etc, the commands they're typing to do so are generally credible. Sure, a display full of xterms isn't very exciting to watch, so they dress the xterms up with the usual MovieOS silliness of big fonts, translucent windows, etc. But look past that to what is actually being typed, and it's credible -- rsync files from bad guy's terminal to a USB thumb drive, ssh/scp back to the good guys, etc.
Compare & contrast with, say, "CSI: Miami", where the IT forensics nerd spouts off nonsense that half-correctly over-explains at a third grade level how he's trying to catch the bad guy based on log files on the laptop left at the crime scene, followed by screenshots, in full MovieOS glory, that don't even have any relation to what the actor was babbling about. And to top things off, they then follow up by noticing some possibly useful detail in an unfocused section of a photo found at the scene, so the boss says "enhance that" and presto-chango, you're looking at a perfectly focused, zoomed-in image of the perp and the murder weapon. I can't say how realistic the show is with other branches of forensics, but anywhere they get a computer involved, it's completely off-the-wall.
And likewise with the other CSI shows, or Law & Order, or any other modern cop show. But "CSI: Miami" seems particularly awful here.
"Alias", on the other hand, is at least accurate enough to not be distracting to someone comfortable with computers, and even more specifically, the Unix shell. That, I think, is as much as anyone can reasonably expect in pop fiction entertainment.
Yeah. That's the One True Path to a Rewarding IT Career. On one hand, you can make your job seem like "magic", so that every time you do some stupid trivial fix for someone, it's mysterious and inaccessible. This is great, because it makes you seem like a miracle worker, but on the inside it gnaws away at your soul having to do the same monotonous grunt work all the time. Plus, if they ever catch on that these fixes are trivial, you've just tricked your way out of a job. On the other hand, you can make plain what you're doing, so that every time you do some stupid trivial fix for someone, they can learn from you and fix it themselves next time. This is great, because it has the potential to free you up to work on more interesting projects in the long run, but it does run the risk that you'll seem less like a miracle worker. But, if they catch on how to do these trivial fixes for themselves, you've just tricked and taught your way into a promotion. "Teach a man to fish, he'll eat for a day. Teach him how to fish and he'll eat for life." The last thing we need is a "mystery of how IT performs its functions". What we need is transparency, and a way to empower people to solve their own problems so that we can focus on the truly difficult aspects of the job. I've used VNC-like programs to help users fix things at their desk while I was at mine. It almost always went more smoothly if I either had them on the phone while controlling their terminal, or if I left the terminal interactive and left open a chat program (IRC, AIM, iChat, even just leaving open a text editor where I could type messages and they could respond) so they could see what I was doing, I could explain why, they could give feedback to help me solve the problem more quickly, and I could show them how I resolved the problem so that they could fix it themselves next time. In 9 times out of 10, if the problem came up again, they didn't need my help or my time to set things right again. This curtain mode seems like a cute feature, but to me it seems best reserved for situations where the users can't be allowed to see what you're doing -- you have to enter or view admin passwords, you have to access systems that the users shouldn't see, etc.
You have to read the article to put the quote in context. The first paragraph, under a photo of a man facing a robot, reads as follows:
Later on, the last paragraph, partly quoted in the Slashdot writeup, is:
As with many other things in life, it makes more sense in context. Here, the journalist is pulling the common writer's trick of using a catchy side anecdote as a framing device for a broader piece, using it to hint at how the topic being discussed -- the embrace of robot technology in Japan -- exists in a broader context of immigration, xenophobia, technophilia, and social environment.
Then they aren't missing the point. To quote the article:
They get it. Or at least, the Guardian's reporter thinks they get it.
I'm assuming that the through-the-window models won't help you, but one of the portable ones might. To pick one at random, consider this portable A/C unit. The advantage of something like this, as opposed to the window fans that some others have suggested, is that it should come with an exhaust hose that you can channel to either the furnace's exhaust pipes, or to some other appropriate outlet elsewhere in your home. Something like that ought do do exactly what you need here.
Precisely. I can't think of any way that being able to edit posts after the fact would do anything less than completely ruin moderation.
The only solution I can think of is to allow people to either [a] append a change log / footnote to their posts, so that they could append thoughts to the intact original material, or [b] come up with a way to embed some kind of revision control system, so that you can make edits without amending, but visitors would be able to see how a post has evolved over time, and will be able to see what the moderation level was at with different iterations of the comment, and moderators could attach their revisions to specific point revisions.
The first option is much simpler, but not as elegant -- at least in terms of having tacked-on footnotes to revised comments. On the other hand, the second option seems like it would be very complex both to implement and for users to learn how to work with. I'm not sure that the complexity would be worth it, because it raises all kinds of edge cases -- should mod points for revised comments get invalidated, or pro-rated, or left alone?
Obviously, things are broken now, but allowing comment revisions seems like it could be a cure worse than the original disease...
You deal with it the same way anyone else with a job does: you learn to set, and meet, proper priorities.
An employee's job is to satisfy your manager's expectations that you are fulfilling your duty within the organization. This is true for anyone with a job, no matter what that job might be -- programmer, sysadmin, manager, garbage collector, whatever. It's true for anyone with a boss -- and pretty much everyone has a boss, whether it's a manager, a VP, a board of directors, the voting public, whatever.
According to you, your manager expects you to, quote, "that stresses correctness in programming first, amount of time needed second, features third". That's it then. That's your job. Period. If your manager is doing his job, then that's all you should need to worry about.
Your manager, by contrast, is responsible for fulfilling the expectations of upper management, namely, in "stressing features and amount of time needed first and correctness of programming a distant second". In practice, that means that he has to walk the balance between doing things right by his staff -- code correctness, then time constraints, then feature completeness -- and doing things right by his bosses -- features & time, then correctness. His job is to allocate staffing resources so that his team is doing things properly and at the same time keeping upper management happy.
The concerns of staff two levels up the chain of management aren't your problem; they need to be steering the direction of the business, and counting on the people working under them to be able to deliver. Likewise, the constraints that you need to be working within -- doing your job right first, and meeting time & feature needs second -- should not be the concern of the upper management; they have broader things they need to be focusing on.
Now, I realize that this is kind of idealized, and not all companies provide an environment where this is possible. Some companies are led by people that want to be very hands on with what their staff are doing, and sometimes that can even be a good thing. Other companies want to break down barriers between layers of management and staff, and that can also be a good thing. But having too many cooks in the kitchen, to rob a phrase, is rarely a good thing. If your company is big enough to have multiple layers of management, and they trusted your enough to give you a job, then they need to trust you to do that job, and they need to trust your manager to set your working priorities, and they need to focus their own efforts on steering the company itself so that you have something worth working on and the long term prospects of the company are assured.
And all that said, the one theme common to all of these different job functions is that everyone has to be able to understand and set priorities. In these days of relentless cost cutting and ever-increasing productivity, most people have more job responsibilities today than people did a couple of decades ago. The people that keep their jobs and keep getting promoted are the ones that figure out how to doing their immediate job right (so that it makes their direct manager happy) and making their manager's job easy (so that it makes the upper level manager happy).
And part of this means figuring out how to manage your time, what to focus your efforts on, and what parts of your job can be safely ignored. (And yes, implicitly, that means that some people won't be happy; you have to learn to live with this, unfortunately.) If banging out a sloppy version of your code gets something to your managers in a third the time that the "correct" version would have taken, then sometimes that's the compromise you have to make. But if you can make the case that spending the extra time to do it "right" will have benefits that offset the lost time & functionality -- for example, it can make future versions faster to produce
He was being a bit optimistic, perhaps, but he's basically summarized the way things stand, or that they seem to be heading. And this was first printed in the original UK issue of Wired magazine, so that was what, a decade ago? The whole essay, What have we got to lose?, is fascinating stuff. Go read it if you haven't come across it before -- you'll be glad you did.
But then you're stuck using XFree :-)
Anyway the point wasn't to be a troll about it -- and in hindsight, I apologize if I came across that way. I'm just pointing out that while subtle tricks like subpixel rendering can do a good job at making the most of existing display technologies, even with their help, you're still getting a small fraction of the resolution available to even the cheapest of printers -- and those printers can often go much sharper if you want them to.
In order to get anywhere near the quality of print, display technologies need to either get radically more clever, or have to be superceded by something much finer grained. The way things are now, and have been for the past decade or more, display resolutions are an order of magnitude coarser than print ones, and on the whole, even things like TFT and subpixel rendering have not done enough to close the gap.
<half-facetious> Of course, the obvious problem there is that they'd be stuck in Utah. </half-facetious>
I'm sure Utah is a lovely place with lovely people, but I'm also pretty sure that it's a drastically different culture -- teetotalling button-down rural red-state Mormon on one side, drunken easy-going urbane blue-city Catholic on the other. That's stereotyping a bit, for which I apologize to both sides, but I think there's something to it -- I'm just not sure how well the hosts or the guests will get along together.
More importantly -- far more importantly -- a lot of these people don't want to be that far from home. Otis Air Force Base on Cape Cod was ready to take on 2000 refugees up until today, but now they're saying that few if any are actually going to show up. The main reason is simply that most people don't want to be that far from friends, family, or home -- even if that literal or figurative home isn't something they can ever go back to. Moving to Massachusetts, even if only for a few months, could feel like an admission that they can never go back to their homes, their belongings, and their memories, ever again.
If the long-term situation in New Orleans really is as bad as it seems to be, then I'm sure it's inevitable that there will be an exodus of people away from the city and from the region. But that's a painful step to take, and it may take a while before a lot of the people affected will be able to come to terms with this change. The collective trauma on the American psyche could prove to be far more painful from Katrina than it ever was from 9/11 -- then, we had an event that hurt a few thousand people in a few eastern locations, but this, in addition to killing at least as many people, looks ready to scatter hundreds of thousands of shell-shocked people all over the country. It could take decades to recover from this, if we ever do.
Wait, let me check my math here.
So you're saying that, with the magic of advanced rendering technology [only for Windows, yes?] on a high-end & presumably expensive display, you can ideally get ... 133 x 3 = 399 or ... 399 / 1200 = 0.3325 ... So, about a third as good as you can do with a hundred dollar printer and a penny piece of paper ? Hm...
Somehow, this doesn't exactly disprove the assertion that print quaility is still far better than anything a consumer computer can do on screen today, or in the foreseeable future.
It may be massive overkill for this, but I love using Request Tracker (RT) for ths kind of thing. It's primarily intended as a bug tracker / ticket tracking system, but it it's extremely featureful & flexible, and several other tools are built on top of it, including a FAQ manager, an incident response system, and an asset / inventory manager.
I for one find a lot to like about RT, which is why I currently use it at home for tracking regular household chores just as I used it at my last couple of jobs for tracking all the little projects I was involved with. One feature that may appeal to you is that it's very easy to set up queues for different problem areas. If you have 10 project teams to manage, you can set up one (or more) queues for each of them, and people using the system can be set up to have access just to their own queue / project or to multiple queues / projects. People can create individual tickets for individual tasks / to-dos, and tickets can be linked ("refers-to", "parent", "child", etc), so you can set up arbitrarily complex dependency graphs among a set of tickets -- one ticket might be the umbrella for a project, and any number of other tickets can be linked under it as children or grandchildren or ... whatever you like. And, of course, it's possible to add notes to these tickets either via going to your RT server's web site or via email messages to the RT system.
RT is all written in Perl and available under the GPL, and it'll run anywhere that Apache and mod_perl will run (Linux, Solaris, Windows, OSX, etc). Because it's so open, there's a lot of contributed add-ons available for it, as well as a pretty good collaborative documentation Wiki for the system. It can, admittedly, be a bear to install -- it depends on a lot of CPAN modules, so getting them all installed & configured can take a while if you're not lucky enough to be on a platform with a good package management system -- but there are installation guides for most major platforms, so you should be able to find a suitable one to start from.
Now, all that said, some of the other commenters noted that for the truly disorganized, no tool is going to get you past your own habits. Certainly, that's true, and coming up with a system for keeping yourself organized is tremendously important. In my case though, I have found RT to be a very useful organizing tool for my own needs, both at work and at home. It is, admittedly, a pretty complex piece of software, with a large number of nooks & crannies to learn about. But for starters, you don't need to know about any of that. Just being able to install it and start using it is all you need for now. If you need to, turn to the maili
I think that's precisely it.
I just left a job where all the Linux machines were running Debian Stable [Woody], unless there was a specific requirement for something else (e.g. a commercial application that wouldn't run reliably on anything but RHEL).
Everything was buggy as hell, but the admins were okay with this, because it was "stable". Desktop applications had thorougly well documented bugs or feature omissions that had been corrected upstream years ago, but if it wasn't available in stable (or maybe in backports.org, then an upgrade was strictly out of the question.
Therefore, I was constantly explaining to new people why CUPS crashed all the time, or why getting Gaim to connect to the Jabber server was such a convoluted process, or why we couldn't run Thunderbird or Firefox because the standard builds required a newer version of libc than what was locally available. Etc. Ad nauseam.
The logic for Debian stable comes really close to making sense, without ever quite working. You should be able to install the current Debian stable on a system, deploy it, and aside from occasional security patches, it'll always maintain the same state it was in the day you deployed it.... warts and all. And that's the catch -- there's lots of grimy old warts in a lot of the packages that had upstream fixes months or even years ago, but none of this is available to you unless you're willing to [a] build your own packages (and forego the wonder that is apt-get), or [b] upgrade to Testing or Unstable (and abandon the promise of stability & consistency, which isn't without merit).
Debian Stable is a great idea. It's disappointing that the reality of living with Debian doesn't live up to the naive promise of that idea. I can see where it's just the thing for a server that you want to set up and then ignore for a nice, long, mostly reliable decade, but for anything that you plan to put on your desk and have to cope with from day to day, it's just painful to live with.
That thing clearly has too many buttons on it to be an Apple mouse :-)
I hadn't seen that, but it sounds like it wouldn't help. On a network of maybe fifty desktops and fifty servers, I can think of two XP machines, both of which are just there for QA work.
Now if it worked on Windows 2000, that would be something, and if it could wake up to run Adaware / Spybot / AV scans it would be something, and if it could do all of this remotely it would be something, and if it could manage responding to SNMP queries it would be something. And if it worked on OSX or Debian, then it would be something.
But it doesn't sound like it does any of that, or at least it doesn't without a good bit of manual tweaking. Hrm...
To be honest, no, not least because we have such a mix of hardware & software (a pretty even split among Debian Stable [Woody], Windows 2000, OSX 10.3/Panther, plus some oddball Windows XP, RedHat, and Solaris machines).
Would these things work across such a mix? I was assuming that it would be too much trouble to bother with, but maybe I'm wrong...
The limited testing of done -- say, trying to ping or ssh to a sleeping Mac that had been configured to "wake on network administrator access" -- has never gone well. If you can get a connection at all, it's only after waiting a minute or two for the machine to spin back to life, during which time the attempt to ssh in had usually timed out. I suppose that a bit of tweaking could get it to work, but that's just one target, and there's a whole bunch of them here to be dealt with...
At my job, we have all the servers & workstations configured to run 24/7, for several reasons.
On each computer, scheduled jobs (cronjobs on Linux & OSX, scheduled tasks on Windows) do things like backups, updates, antivirus & antispyware scans, etc. Making these things happen automatically and outside of business hours makes life much easier for the people that have to maintain all these systems (i.e. me). The main downside is that occasionally an operating system will force an unattended, unprompted reboot, causing the owner of that workstation to lose work. This is annoying, but we warn people in advance that it could happen, and they need to save their work before going home; the alternative -- manually finding out about & doing these updates machine by machine -- just isn't tenable.
The other benefit though is that we have SNMP monitoring of all hosts throughout the day. If a machine is having a hardware problem -- say, the printer is running out of toner, or someone's hard drive is filling up -- we get alert emails about it so that the problem can be fixed. This also allows us to know what machines are down at any given time, and have a reasonably small window indicating when it went down and when it came back up; this can help narrow down time frames for events like office power outages or, should it happen, the theft of a workstation.
I suppose we could get some of these benefis while also providing nightly downtime, but the benefits of having continual monitoring & maintenance are strong enough that there hasn't been a lot of call for it -- and when someone brings the idea up, the proposal usually gets shot down by the people managing the network.
If it were possible to bring this equipment into some kind of standby mode where it was still possible to do basic network tests (continually pingable, occasionally query for things like disc space, once-nightly wake up for updates & virus/spyware scans, etc) then maybe the idea would fly, but as things are now, there doesn't seem to be a good way to get these benefits other than by just leaving everything on all the time.
If nothing else, at least the monitors get turned off when they go idle...
*ahem*
From the comment:
In other words, an article in the Christian Science Monitor -- a fine newspaper, but not a scientific journal by any stretch -- in which the reporter casually asserts without citation that "other scientists" have "reviewed" the results, does not an independent confirmation make.
You can't just wave your hands and say "oh yeah, others have repeated it, others have reviewed it, we're done here." Who are these others? What exactly did they find, and how closely did everything match the original inputs & outputs? What kind of "review" did they do? We're still just dealing with anecdotes and hearsay, not scientific analysis.
What the grandparent poster implicitly asked for, reasonably, was [presumably refereed] articles in [presumably credible] scientific journals documented that other [presumably non-pseudo-science] researchers had taken the procedure described here, replicated the experimental apparatus, conducted their own trial of the experiment, and then verified that the results they obtained were in agreement with the ones predicted by the original researchers. If all that happens, then, and only then, are we getting somewhere.
Until then, this doesn't sound like much more than yet another cold fusion pipe dream.
And that, now that you mention it, has me wondering if it's an accident that "sith" is an anagram for "shit". Hmm....
That or take a few first looks at it, if you like.
*Ahem*. RT does not use PHP; it's a mod_perl (and specifically, a Mason) application.
Quoting from RT's feature list page:
That said, RT is a fantastic tool. I've used it at the last two jobs I've worked at, and if it's not there next time I switch jobs, I expect to introduce it. It can be a bit fiddly to get installed, as it depends on a couple of dozen CPAN modules, but the Wiki documentations's generic and specific installation guides try to make this as painless as possible, and if you get stuck there's always the mailing lists and paid support. And once RT is up and running, it's stable, versatile, flexible, adaptable, and just all around a great tool for managing a collection of on-going tasks.
If it's good enough for NASA, Merrill Lynch, DynDNS, Perl (it's the bug tracker for the Perl language), and others, then chances are it's probably good enough for you too. :-)