If the system has been hardened and unnecessary services and features diabled, it can go months, even years without a patch or update. If the system is configured according to "consumer defaults" a few days may be too long.
As others have indicated, update ASAP when you return. If you need certain specific service packs or anti virus updates, you can also download them onto another machine (perhaps a friend's) which has been updated all along, and run them from CD before connecting to the net.
A properly hardened system is immune to the vast majority of exploits; a system which hasn't been hardened isn't necessarily safe even if updated daily.
> how do you computer and IT professionals out there put in your notice of > resignation (if you are with a permanent employer, and not contractual), > and not get immediately shutdown, and shunned away from the computers?
There is no guaranteed way. For many firms, disabling computer access is Standard Operating Procedure, and will continue to be.
> The CIO immediately thought I was going to do something terrible to the > system, and destroy accounts, and any other activity that I have access > to, but I was giving him notice that I was leaving. What is the professional > thing to do?
Exactly what you did. The CIO didn't -necessarily- think you were going to do anything. But some guys do, and if they disable access as a matter of routine, their asses are protected better. It is much less of a problem to prevent you from doing any work than to -fail- to prevent the next guy from doing damage.
Don't take it personally, unless you have heard specific comments on your character or performance.
> I submitted a letter of resignation yesterday, and today I'm at home posting > stories to my weblog and Slashdot.
Well, the blogging and SlashDot part might make employers nervous. You might consider waiting to post, just to avoid letting something slip through without careful thought.
I just make it a policy not to talk too much about jobs and employers after I've left. If you don't say anything, you can't say anything by mistake.
> I gave my employer two weeks notice, and almost immediately, I had my > accounts disabled, and my permissions revoked on all the computers at my > work, which makes me unable to do anything in my position of being a > 'Systems Analyst/Systems Administrator'.
Not necessarily. Often, I've used the period between notice and actually leaving to write documentation, follow up in person with others, giving them information they should have and answering questions. You can still work, you just need to change the focus from "what I usually do" to "what I can and must do to transition."
> I spoke with the HR rep, and gave her my notice yesterday, then I spoke with > her today about what had happened to my access, and they honored my > resignation... 2 weeks early. (Luckily, I'm compensated in pay for the next > two weeks).
Sometimes that's the best. But truly, in many cases the next step after filing the letter of resignation is to be escorted off the premises by security. Again, no reflection on you; it's just SOP.
> isn't it a bit brain damaged to ship something on 7 CDs? > That's like back when we shipped Windows on 15 floppies, when CDs were on the > fringe of new technology. DVDs could still be considered technologically > frenge devices, but when every major game console (sans Gamecube *rumble*), > new PC, and Laptop ships with a dvd player.. well, it's hard to ignore it > as a publication medium. Those 7 CDs would fit perfectly on a DVD with room > to spare.
You're right, in the sense that DVD is -much- smaller, and MS has been pestering the developers who subscribe to go to DVD for years. However, the subscriptions aren't set up to select DVD or CD -by product-; it's -all CD- or -all DVD-.
This means that in addition to getting the DotNet development environment on DVD, you'll also get the test platforms (foreign language OS versions and legacy operating systems) on DVD. I waited longer to switch mine over for that reason.
For testing purposes, you often want to use the older hardware, particularly for the foreign language versions. At one firm we had to work with European laptops that were -seriously- underpowered compared to the top of the line Dells we were using in the US.
Having CDs makes it easier for using the older hardware. But at this point, I'd agree that DVD just makes the most sense.
Despite the sarcastic comparisons to Unix, Windows NT has had the capability to update most system components while in use for a long time.
Typically, the user would exit applications before installing, but this is unecessary most of the time.
However, this capability has always required the person writing the installer program to not sabotage this capability by ignoring Microsoft's installation guidelines. Since the refrain from most developers is "what installation guidelines?", problems are frequent in practice.
The article indicates that the primary change is that this "Restart Manager" will discover dependencies at run time, and do the work of shutting down and restarting applications and services (daemons) -in their current state- automatically. It would do nothing for applications that the user can't do now, and nothing for services that can't usually be done by the administrator.
But automating it is nice; I can see where this would be useful.
>> With generally good, but less than perfect accuracy. Wikipedia is not the >> best source of information on a subject this hotly debated.
> Of course I accept that Wikipedia isn't perfect, but with the greatest > respect I don't think you can make a case that exit polls aren't: > i) Used the world over to predict election results, or > ii) Trusted by the majority of democratic processes as at least a good > guide to election results.
I didn't. But the wikipedia article referred to went -much- further in its claims. That's why I suggested going to more neutral sources.
> Fact: Exit polls have been trusted...
No argument. But accuracy is always limited by some margin for error. There are known, -real- problems with all traditional polling methods, as the nature of the society we live in is changing. Exit polls are no exception, though they are still -much- more accurate than other polls, and do not suffer from some of the same problems.
> Fact: Since the 2000 presidential election...
No argument, although I am not comfortable with assigning one and only one cause for the inaccuracies. I don't argue that the Diebold machines are -a- cause. I don't even seriously suggest that something else is the primary cause, although I'd listen to an argument someone else made.
My real concern is that in the quest to find the one and only one cause, we patch one hole in a broken system. I'd like to fix -all- the problems.
> Fact: The 2000 and (specifically) 2004 elections favoured a party whose > popularity was dropping.
Based on what? I'll accept this as a possibility; but I'll want to see details. From my point of view, -both- parties have lost an enormous amount of popularity and credibility. Again, I am not saying "Republican good, Democrat bad"; I'm saying most people I speak to don't think much of either party.
> This is the same party with strong links to the Diebold...
True, but the other party is an enabler, pushing for fast replacement of fundamentally working punch card and OCR systems with untested touch-screen crap in order to get the public -perception- of addressing the problem. Both parties are at fault for the current debacle.
> Fact: The party pushing for a lack of audit-trail...
Again, based on what? What I have seen is officials of both parties at -all- levels being equally obstructive regarding auditing and paper trails. I'm not arguing about the problem; but I haven't seen the white knight on his white horse battling the dark ogres.
>> Many of the inaccuracies cited in Florida and Ohio in particular are not >> evidence of election tampering as much as evidence of the fact that election >> jobs are handed out to party hacks who aren't competent to do any real work.
> Granted, it could conceivably be lack of education or training, however:
> Since the 2000 elections there hasn't been a radical change in the training > processes of exit-pollsters, so the exit polls are unlikely to have suddenly > become more or less accurate, meaning the election process itself is somehow > at fault.
Again, I don't disagree that the process is at fault. Simply that the deviations noted are within the tolerances for error -without- a partisan plot. They are higher than they ought to be, and higher than they would be in a working system, but still possible without a conspiracy. With a broken system, it is quite possible for the errors to not cancel each other out.
I'm not even saying there was no tampering; I'm saying there has been tampering with all elections since the process began, by all parties. I'm saying that deviations in statistics and polls are insufficient in and of themselves to take effective action. To fix the problem, we need an audit trail.
Is it suspicious? Hell yes! Is it a smoking gun? Hell no. You basically have a building that burned and a guy who profited on the insurance.
> Exit polls have been used the world over to predict election results for > decades. [link to wikipedia snipped]
With generally good, but less than perfect accuracy. Wikipedia is not the best source of information on a subject this hotly debated.
> So we have a single event where the long-working exit polls (which are > normally accurate) are suddenly and significantly different from the final > official tally. This could be written off as a statistical fluke, but the > Diebold and ES&S machines are already suspected of widespread insecurity > and/or deliberate tampering, and then when it all hits the media the > administration announces it won't be conducting exit polls any more?
Tha's somewhat oversimplified, There are -without doubt- problems. The immediate leap to deliberate tampering is not the only explanation, especially in light of historical incompetence of election workers. The reality is that finding, training, and supervising the volunteers who do the work is a large task filled with problems.
Many of the inaccuracies cited in Florida and Ohio in particular are not evidence of election tampering as much as evidence of the fact that election jobs are handed out to party hacks who aren't competent to do any real work.
Many pollsters are changing their methodologies to deal with problems that have been affecting accuracy for some time.
> Why, when they've been used for decades without problem, are exit polls > suddenly considered dangerous or misleading? Apart from, that is, their > potential to provide an indication of election-tampering?
The problem is that they can only be used to support a -charge- that the election was botched. They can provide no value in determining the cause of inaccuracies, or determining culpability.
To actually audit the elections, we need an audit trail, not a secondary source of information. I'm not arguing against most of your points. You made some good ones. But you let it fall into simple two-valued logic which I feel weakened the value of your post.
How sure are we that businesses backed off "because of controversy"?
I see assertions in the articles, but no basis offered for the opinions expressed. I wonder if this isn't a case where corporations simply chose to direct the funds to other opportunities. Not "backing off in fear of the massive power of CREATIONISTS", but rather saying "Nah, I think we'd rather back this one..."
My own experience in fundraising suggests that the second is a fairly strong possibility.
> As an attorney I can tell you that lawyers tend to have a better grasp of > technology than many other professional groups that I come in contact with.
You're probably right, but that doesn't necessarily mean much. The truth is that a little knowledge is a dangerous thing. A lot of people cause worse problems by thinking they know more than they do. Attorneys are not immune to this.
> You have to be pretty smart to get into law school these days and that > generally translates into a better understanding of current technology.
Can't agree. Make it "better understanding of how to _utilize_ current technology" and I can agree.
> Furthermore, I doubt that Sony's rootkit scheme was unconditionally approved > by legal...Companies, especially large companies like Sony, are not run by > attorneys; they're run by professional managers. It's not uncommon for > managers to end run legal or simply ignore legal advice when it's not what > they want to hear.
Or accounting advice, or IT advice...
Very true. Most of the really bonehead plays I've seen managers pull in the last several years have been because they -refused- to ask for or accept legal and/or accounting advice.
> 1. Version Control - find a VC system everyone can agree and use it > religiously, whether for scripts, programs, or even web docs. I've use > CVS mainly, with a little Perforce, and Subversion is good so I hear.
Also, since the shop has never had an IT department, make sure everyone knows -how- to use an RCS. I had a project a couple of years back where one guy didn't use the RCS. After a few times I badgereed him to check in, we talked and I discovered he didn't really understand version control. So I spent some time teaching him.
> 4. The Brain Book - there's nothing I hate more than starting a new > job and having to learn all those server names, IP addresses, what I'm > supposed to have access to, where in the directory tree the stuff I > works on live, what types of DBs we use and their versions, etc. So I > developed the Brain Book, where I would write these things down as I > learned them, to have a point of reference. It's a good idea to do this > for all your major projects, so as new people come on, they can spend > less time learning their way around and more time coding.
We do this as part of an orientation package. Server names, standard share points, who is in charge of what, standard test logins to use, etc. Put it in a document, print it out for everyone new.
> 5. Code Review - everybody's coding style is different and sometimes > they don't mesh well or there are divergent opinions on how a particular > task should be coded out. Get your programmers together in a room and > hash things out as a group. It will provide everyone with a say and may > open up some people's eyes to new ways of doing things.
Very good advice; this also smooths out problems where any convention is just as good as the next, as long as everyone is consistent. Hashing this out as a group prevents cases where 9 people are asked to change the perfectly acceptable way they do things to conform to the lone other guy's ideas.
> Oracle VS SQL Server. Oracle is free for one processor, 2GB of RAM and a > 4GB database size. It runs on multiple platforms and it's target market > is for higher end databases. It can mount XML, TAB delimited and other > files natively as tables. That is very very nice to developers.
I'll have to take your word for that; I don't know anyone who has needed that particular feature. The only apps I've seen that needed to access XML or TAB delimited data as a table have been -very- tiny utilities; VBA macro in an Excel spreadsheet kind of thing.
> SQL Server has the DTS stuff. DTS is very nice for moving data around, > but not as nice as actually mounting files as tables.
DTS is -very- useful for moving data around. I'm not a DB admin, but I've not seen a DB admin for SQL Server who doesn't use DTS as a key part of his daily work.
> Oracles Enterprise manager is very comparable to Microsoft's,
Except for the crappy install and configuration (under Windows). Oracle's EM (and many of Oracle's tools, actually) are a giant pain to set up and configure properly anytime the installer fails, which is depressingly often. And Oracle dies with crappy error messages if everything isn't just so (but the error messages are still better than the error messages for IBMs CICS gateway drivers; wrong path gave a "Division By Zero error". At least Oracle gave a legitimate "DLL not found"):)
> Now I find the core difference in Windows and Linux is that most shops > do a LOT more on one Linux/Unix box than one Windows box. Most Windows > shops (ours included), have a Windows server for one specific task, > perhaps two tasks. Most Linux and Unix boxes run many different tasks > and as such you need far less of them.
Very true. I think this is nearly universal.
> Perhaps this is just the attitude of Windows users to purchase more > servers because they are "cheap" but I can say that every place I have > been this is the case.
It also might be related to the fact that configuration changes almost always required a reboot in the past under Windows. That's much easier to manage if you don't have to interrupt more than one core business task with the reboot. Taking down one business application for a reboot is one thing; taking down three unrelated apps that are on the same box is another.
> Most Unix/Linux guys you talk to mention two things, their uptime AND > the amount of crap that is running on their boxes. Most Windows guys I > talk to mention the number of servers they manage. So in short this > needs to be factored in as well. This issue may also come from all the > DLL hell that has plagued Microsoft for years, or the fact that it was > difficult to impossible to run different versions of SQL server on the > same box.
Not just SQL Server. It's historically been -very- difficult, often impossible, to run two separate versions of anything on one Windows box (reliably). The shared DLLs screw that up all too often. It's better now, but there are too many legacy apps out there that don't play well with others.
> Perhaps we should consider the actual damage done. Is the damage so severe and > widespread that someone needs to (essentially) pay with their life?
Considering the actual damage is important. However, the logical leap that imprisonment is essentially paying with their life is only valid to the extent that working for a living is "paying with your life", and working to pay taxes is "paying with your life." It's a phrase geared to obscuring rather than clarifying.
> Is this really a terrible abuse of power?
No, in the sense that this was not part of a "vast and terrible plot." Yes in the sense that the action was illegal and unethical, -and- totally disproportionate. In order to protect "intellectual property" of dubious worth, Sony exposed millions of their customers to potentially devastating damage.
> It didn't take long for the information about the rootkit to become publicly > available, and those who care decided not to buy any of the Sony CD's.
The fact that the person who drove drunk (Sony) did not cause loss of life (yet) doesn't affect the base punishment for taking an action that is flagrantly irresponsible. It simply means there is no need to add additional charges based on loss of life.
I said "yet" above because of the fact that merely because the rootkit was exposed does not mean all the remediation has been done. In a corporate environment, it make take weeks or months to identify all compromised machines, apply the fixes, and verify the work. It may take even longer to get most of the machines belonging to common users remediated. The cost may still be considerable, and Sony may still turn out to be responsible for severe damage to some systems.
> This sounds more like a company (Sony) made an uninformed decision to > purchase a bad technology. Microsoft is just as culpible for their > administrator-rights-for-everyone and allowing autorun by default.
Not quite. Sony made an uninformed decision to purchase a bad technology (1) which compromises other, non-Sony software on user PCs, and (2) installs without adequate notice.
There is a difference between Ford installing a new anti-lock brake technology at the factory, or in a service call based on a recall notice, which may turn out to be crap with bad side-effects, and Best Buy installing a device that modifies the brakes in a Ford while ostensibly upgrading the speakers in the car's audio system.
One is stupid, arguably irresponsible, but with a certain minimal disclosure and expectation that the change might be made. The second is not only irresponsible, it is actionable.
>...give the law a chance to work. It does take a while.
Good advice.
> There will also be class action suits filed against the company. This will > hurt management, as well as the shareholders.
Hopefully, the shareholders won't allow Sony's board to harm the shareholders excessively to protect the managers.
>...their shirt can't instantly become six billion more shirts, which you can > give away for free (or sell for next to nothing, like AllofMP3.com does) and > take away any reason for anybody else to buy one from them.
Correct. Not "instantly."
But designer clothing does in fact get copied, and very quickly. Instead of trying more and more complicated ways to prevent copying, they've altered the business model to maintain their profits, and depend on the law to reign in the worst abusers.
They don't ignore the illegal duplications, anymore than retailers ignore theft. But like retailers, they recognize that a certain amount of theft is a cost of doing business. They don't antagonize all their customers in an ill-conceived plan to reduce shrinkage to $0 (at least most of them don't, yet).
> Selling recorded music is a multi-million dollar industry, the owners of > which surely don't want to just give up, just because technology has made it > fantastically easy to rip them off.
Well, part of the problem is that it is a multi-million dollar rip-off, and they don't want to reduce their own excessive profits. I'm not just talking about ripping off the consumer; I'm talking about ripping off the artists, as well.
The recording and motion-picture industries are notorious for "creative accounting" being used to rip off their artists, distributors, partners, -and- consumers. A search for "fraudulent accounting" and "recording industry" turns up a fair list.
One of the key alternative suggestions is based on the idea, "don't try to rip people off." Cut fair deals with artists, distributors, partners, and consumers. There is evidence that this works, on the rare occasions it has been tried.
I don't illegally copy music. But I also don't buy very much. The truth of the matter is that most of it isn't very good, and almost all of it is ridiculously overpriced.
> It's been a while since I've worked on Windows drivers, but I believe > certification also means that the driver has passed Microsoft's very rigorous > driver tests.
Yes and no. Microsoft extensively tests certain aspects of the driver, using certain hardware. They don't test all hardware configurations, just typical ones. And they do nothing to certify certain "optional features" of drivers.
HP is notorious for putting crap features in drivers for a lot of their printers, with the result that Microsoft's generic HP printer drivers are usually -much- more stable than the HP supplied ones. They can't always access all the Cool! New! Features!, but they work fine and are generally much more stable.
This is not just true of HP; as others have mentioned, graphics boards are another area where manufacturers pull stupid stunts.
>> It's important to make sure that the major labels realise that while DRM is >> legal, there are limits to what people will tolerate - and damaging peoples >> machines is not something that people are going to tolerate.
> It's not simply a question of tolerance or not; some DRM may be "legal", but > (IANAL) installing a root-kit on someone's machine without notification or > permission almost certainly isn't.
In other words, DRM is legal, but that does not mean that -everything- that vendors wish to do to protect their content under DRM is legal.
It's like protecting your home. I can set up alarms and locks, I can buy a gun. I -can't- tie a gun to a trap and set it up to kill a criminal who breaks in.
Some points based only on the review.
on
Write Portable Code
·
· Score: 3, Interesting
Note: I am a C++ programmer. I didn't read the book, just the review here. Apologies in advance if anyone takes offense.
> The first couple of chapters introduce the reader to portability concepts > and then to some of the specific portability features of ANSI C and C++ > that are used throughout the rest of the book.
I think enough software is written in languages other than C and C++ that any serious author should put C or C++ in the title when the book is C or C++ specific.
It's not wrong that the author or publisher chose to call the book "Write Portable Code" instead of "Write Portable Code in ANSI C". But it does make me question if the author's knowledge is limited by a single-language bias.
> The last two chapters look at some alternative ways of getting portability. > Scripting languages are discussed and the pros and cons of each ones > portability is weighed. Lastly the use of cross-platform libraries and > toolkits is addressed.
Given that scripting is limited to one chapter, wouldn't it have been better to refer the reader to other works with more detail and value, and only give a paragraph or so? Particularly since the book is not trying to be about portable code in general, but portability in ANSI C, and discusses nothing (AFAIK) about higher-level compiled languages.
The book's about C. Why clutter it with a chapter on Ruby, Python, and JavaScript/ECMAScript and say nothing about Java, Lisp, SmallTalk, etc? Writing a chapter on scripting languages strikes me as gratuitous filler.
And any non-trivial cross-platform C application is likely to use some sort of cross-platform toolkit. So why only a chapter?
> An example: Rule 4 - "Never read or write structures monolithically from or > to memory. Always read and write structures one element at a time, so that > endian, alignment, and size differences are factored out."
Writing structures one element at a time is a -minimum- required for portability. It doesn't completely address byte-order issues, variable internal data representations, or data element size issues. It just ensures that structure packing and alignment issues that might change based on compiler flags are covered. But change the compiler or platform and all these issues are still there even if you write the data elements singly. They are all unspecified or incompletely specified in ANSI C.
It's better to design a complete data representation format, including embedded version information, or just use a higher level data store engine.
My concern is that many of the other rules in the book might be similarly too "low-level" and incompletely specified. Rather than teaching inherently better, more portable coding techniques, they might just be teaching how to work around the low-level nature of C.
> The immediate impact of this is to legalize reverse-engineering projects of > custom software where the original coder can't or won't produce the source.
Possibly. Certainly it indicates a right to do some degree of reverse engineering, for the purpose of maintaining the utility of software for which you own a license.
This doesn't necessarily mean you have the right to reverse-engineer software for the purpose of extending it's use.
>...the letter of the law, and the text of this decision, would seem to only > permit me to use a disassembler to examine the code and fix bugs.
Possibly. I would argue that maintaining utility might involve more than bug-fixing.
The decision text: "Section 117(a)(1) provides an affirmative defense against copyright infringement for anyone who...makes an adaptation 'as an essential step in the utilization of the computer program in conjunction with a machine,' and (iii) uses it 'in no other manner.'
This would tend to indicate that making some adaptations to allow a Windows program to run, for instance, under Wine, might be permitted. Maybe.
> Where this is interesting is that it appears to overrule the software > industry's assertion that you and I are licenseholders, not owners.
Certainly this indicates that the court feels we own -something- tangible, beyond a license for limited use.
>...The licensee/owner distinction that software companies have asserted is > intended to prevent the creation of a used software market.
Well, that is one part of it. Most of the EULAs that specify license don't try to restrict resale, unless the resale is prohibited as part of an upgrade deal.
> EULAs typically include language that prohibits you from selling the software > "license" to anyone else without getting permission from the vendor first, or > otherwise jumping through hoops.
I'm not sure that's true. I've seen such clauses, but I don't agree they are 'typical'
> Various vendor "authentication" programs that tie serialized CDs to the MAC > addresses of your computer essentially do the same thing--you have to get > permission from Microsoft to subsequently "unlock" that software and install > it on a different PC.
If that were the sole and only purpose, then you'd be right. In fact, Microsoft's authentication expressly permits resale, and reauthentication is basically the same as always.
From Microsoft's Office 2000 EULA, but it's typical of all of them:
"Software Transfer. The initial licensee of the SOFTWARE PRODUCT may make a one-time permanent transfer of this EULA and SOFTWARE PRODUCT only directly to an end user. This transfer must include all of the SOFTWARE PRODUCT (including all component parts, the media and printed materials, any upgrades, this EULA, and, if applicable, the Certificate of Authenticity). Such transfer may not be by way of consignment or any other indirect transfer. The transferee of such one-time transfer must agree to comply with the terms of this EULA, including the obligation not to further transfer this EULA and SOFTWARE PRODUCT."
By limiting it to transfers direct to the end user, it does limit second-hand sales, but you could get around this by using a third-part that doesn't get too close to the transfer, like eBay.
> You may reasonably conclude that software industry lawyers are going to be > working overtime on this.
> They tried to create a feature that the software did not support, > and they did so in a manner that broke the software.
> It's not a software bug, it's a user error. This isn't a bug any more than > it's a "bug" that your Linux box stops working properly if you do sudo rm > -rf/. The users of the product knew better.
True. The problem is more that the software spec allowed this misuse and that it triggered a quietly lethal failure. It's a bad failure mode for medical device control software.
>> You are assuming tight, correct specs - a genuine rarity.
> There are formal languages for specifications (so you can be precise and not > rely on an English language "description" of what is required), and those > formal languages are amenable to analysis. In practice just sitting down and > formalising requirements into this language goes a very long way toward > determining where ambiguities lie, and which parts need to be checked with > the client to be certain you've captured the requirement correctly.
Exactly correct. But the fact that this does not happen is in part driven by how businesses create these kinds of products. I've been offered -many- opportunities to design similar, life-in-the-balance medical software. The only reason I didn't take any of them was because -I- knew the kind of qualifications a designer of this kind of thing should have, and I don't have them. But many of these firms just turn around and hire someone who is not even qualified to -know- he isn't qualified.
Businesses offer it not to professional developers of medical software, but to people who have used a cool programming language or tool that one of their engineers read about in an article in a vendor magazine.
Yes, there is a balancing act. But it has to be done cooperatively with the employee. A poor manager tries to impose the proper balance based on his assessment only.
> Person A may not value those weekend hours as highly as person B, but they > would be very unhappy if they saw that person B got a "better deal".
That's one way of looking at it; not mine. I don't see it as an issue of "valuing [blank] more or less". That may be why I'm so gunshy of managers making these kinds of trade-offs.
It's a matter of the -employee- selecting where and when to make personal life concessions to businesses needs. I'm pretty flexible, especially if given a little notice. But there are some times and areas when I can't be flexible, even if I have some notice.
Managers have to accept that at a certain point, they have to work with the employee to find the best balance for each employee. And yes, they need to be sensitive to the perceptions of other employees. Usually I find it helps if other employees are made aware of the fact that, while "John Doe" isn't coming in on Sundays, he also isn't getting any of their perks, and he's pulling additional hours on other days to help make up for it.
It sounds like you understand this just fine. Far too many managers I've worked with don't.
1.1) And "flex" means the flexibility to leave early and come in late, not just the flexibility to come in a little late and work -much later-.
> 2) Meeting issues. There are 3 kinds of meetings, in my mind: Meetings that > are productive and important for me, meetings that are productive and > important to other people, and meetings where upper management wants to whack > off in public.
2.1) And have an agenda, given to the participants in advance. If you can't tell people what the meeting is about, you don't understand your purpose well enough to have a meeting.
> 5) Privacy. Or, rather, a lack of frequent interruptions.
5.1) Also, a clear appreciation of personal boundaries is good.
> 6) Little things. The best motivator I ever got came at the end of a 3 week > crunch...
6.1) Things like that only work if the boss understands the employee. Lots of incentives like that backfire. When in doubt, ask.
> Supervising means getting work to me and letting me know what's expected on > it.
7.1) Also an accurate picture of the reasons -why- something is needed. Who wants it. And allow the employee to ask questions of people as needed.
> Protecting me means keeping assholes like Phil in business development from > swinging by and talking my ear off for a half hour in the afternoon.
7.2) Or dumping "high-priority" bullshit tasks on my desk at 4 PM when I have other concerns.
> It means not scheduling me for meetings that are a complete and absolute > waste of my time.
7.3) Or planning to use me in a meeting to support your "cool idea" that I already said won't work. If I already told you 2 * 12 = 24, don't walk into a meeting, tell management that 2 * 12 = 16, turn to me and ask, "Isn't that right?"
I really don't want to make you look like a horse's ass; please do me the same courtesy.
> This is true, but if a valid concern about his opinion comes up, he should be > able to defend it.
He should be able to defend it in a fair forum. A lot of times, I've been in situations where I was called into an "impromptu" meeting, to justify my recommendation, which is in line with every piece of serious literature in the industry.
It always boiled down to:
- We decided to to A, in B months and for C dollars
- You told us that that won't work, and showed us numbers demonstrating this
when the same thing was tried at ABC and DEF corp
- You suggested doing D in B*2 months and for C/2 dollars, with phased
implementation to reduce risk
- We found a guy who was at DEF corp who said it woulda worked if they had
used DotNet
- Prove DotNet won't work, given that we just disregarded all the literature,
your opinion, and added a speculative measure. Oh, and all your fellow
employees have been coached to give the answer management wants to hear
I've seen firms lose millions this way.
> A lot of it is in approach.
Agreed.
> You can usually legitimately get away with something like; "Someone suggested > (x) as an alternative to your plan. I'm curious if you have any thoughts on > the idea." If need be, make sure they understand that their idea is still the > official plan, and you're looking for clarification rather than a defence.
My only objection is that "get away with" implies bad things for some non-technical managers.
If you stop right there, it's still the best advice you can give to managers.
> Be honest. Most geeks would perfer if you told them what was going on. Don't > lie to them unless you 100% have to.
I'd say it a little stronger: "Don't lie to them." You can avoiding telling them things, and couch the truth carefully. But if you think you need to tell a flat-out lie, remember this: you don't get to decide if people find out you lied later. That can happen whether or not you ever intend for the truth to come out. If people find out you lied, you will have lost a very important part of the relationship that lets you manage them effectively.
> Listen to them. If they say "we need a week" then go "including delays and > testing?". If they say yes then give them 8 days...
Also make sure they haven't already adjusted their estimate downward to make it more palatable. Sometimes they'll say, "we need a week" when they really need a month.
> Remember they're people. If you're getting a drink offer to get them one, > same goes for if you're making a run some where.
This used to be known as "common courtesy."
> Act like you're one of them because that way you're a friend and not "the > boss".
If it's an act, then it won't work. Don't act. -Be- a person, just like them.
> Having been employee, manager, and business owner at various times in my > career, I use the model that 40/week for a paycheck is the base deal. If one > side wants something more, then they have to offer more in exchange.
> For example, if I'm in a job that offers me nothing more than a paycheck, I > would regard my boss asking me to work extra hours for any other reason than > me screwing up as *exactly* equivalent to me saying to him "mind if I go > take a few hundred from the petty cash tin?" Or: "You want me to work > weekends? Then I get to telecommute when I don't need to be in for meetings."
> When I was a manager I had the rule that "slack is a medium of exchange". > Quiet times, everyone got off at lunchtime on Friday and went down the pub. > Crunch times, we pulled crunch hours - and people were happy with that, > because they accepted it as part of the trade.
That only works properly with an intelligent manager. For example, I don't drink, and I'm not a twenty-something. I've got a full life outside of work. The boss has to understand that taking off at lunchtime to go to the pub is something that most people are cool with, not a universally acceptable trade-off for extra hours.
Also, there is a difference between asking a young guy to come in for a full day on Sunday, when he would otherwise be watching a game in a bar or playing with a frisbee in the park, and asking an older guy to do the same, when -he- would otherwise be teaching a Sunday School class, or coaching his kid's softball team/
Many managers don't see the difference between "I can't work late late, I have to get to the bar before happy hour ends", and "I can't work late late, I have to drive 25 people to [event]." They respond to both cases with accusations of "not being a team player."
> When one side - employer or employee - acts as if they have a right to more > than the base deal without offering anything in exchange,
Or unilaterally renogotiate the terms of the agreement significantly, as in 5-day-weeks becoming 7-day-weeks, etc.
> the other side will get very unhappy very fast. Even if circumstances force > them to give what they're being asked for, the party getting screwed over > will resent it happening, and that makes life worse for everyone concerned.
And if they can, they will leave.
> As far as the general question of how to manage geeks is concerned, my #1 > rule was: "Happy people work harder."
Miserable managers don't understand happiness. They confuse it with perkiness, or peppyness, or blissful ignorance.
> You can't treat an IT geek the same way you treat a marketing guy. They > respond to different things.
In the abstract, they respond to the same things. They want the opportunity to affect the quality of their work, and increase the likelihood that their work will have meaning.
Salespeople will leave in droves when management hands them a canned call script and removes their ability to close sales by removing the authority to offer terms and discounts, just as IT people will leave when given a mandate to work without tools.
I've seen cases where management tried to have the salespeople do the initial work only, and leave the closing to the manager. I've never seen it -work-; the salespeople always leave. But I've seen it done.
> The geek wants reassurances that he's doing a good job all of the time, > especially when things are going smoothly.
As another poster replied, that's horribly oversimplified.
> A marketing guy wants to be adequately rewarded for the big numbers.
The geek and the marketing guy both want to be rewarded. The marketing guy's reward is more direct and tied to something easily quantifiable.
If he's paid an N% commission on sales, he'll react strongly when the boss suddenly declares that the commission is now based on a completely subjective view the boss has of the long-term market growth potential of the sale, and his commissions are cut by 9/10.
The geek is rewarded usually based on the subjective view the boss has of the value of the work done. This is usually completely out-of-touch with the technical merits of the achievements.
So feedback as we go along is more valuable to the geek.
> On my trip Stateside, I was met with nothing but courteousness and friendly > smiles...On the other hand, many of those I dealt with were mind-bogglingly > incompetent. Many operated by a fixed set of written rules and were unable > or unwilling to deal with any situation not dealt with on their crib sheet.
Regrettably, a lot of this is not due to the incompetence of the customer service people, but the incompetence of their superiors.
In many cases, the moronic rules and the "cast-in-stone" nature of them is mandated by managers who are certain they know best.
I recall a time some years ago, in my last "customer service" position, when management decided to change the rules on a particular type of product return. All of us working customer service knew this would piss off our customers. All we asked for is for management to allow us to inform regular customers -before- the change occurred, to ease the transition.
We didn't even want more time, just the chance to tell them prior to beginning the transaction. Management decided this would cause "confusion", and it was mandated as a surprise.
I really got sick of being called a racist white mother-bleeper that first day.
> So between Germany and the US (and from my admittely limited sample space), > one gets the choice between the devil and the deep blue sea; between > knowledgeable but lazy and annoying service people, and smiling minimum-wage > goofballs.
Well, as many people here can attest, a lot of American businesses have tried to use technology to replace the reasonably intelligent service people. On many occasions, I've listened to managers request that our software be so simple they can hire monkeys to do customer service.
You get what you ask for; they wanted monkeys, they got monkeys.
Slashdot Mirror
If the system has been hardened and unnecessary services and features diabled, it can go months, even years without a patch or update. If the system is configured according to "consumer defaults" a few days may be too long.
As others have indicated, update ASAP when you return. If you need certain specific service packs or anti virus updates, you can also download them onto another machine (perhaps a friend's) which has been updated all along, and run them from CD before connecting to the net.
A properly hardened system is immune to the vast majority of exploits; a system which hasn't been hardened isn't necessarily safe even if updated daily.
> how do you computer and IT professionals out there put in your notice of
> resignation (if you are with a permanent employer, and not contractual),
> and not get immediately shutdown, and shunned away from the computers?
There is no guaranteed way. For many firms, disabling computer access is Standard Operating Procedure, and will continue to be.
> The CIO immediately thought I was going to do something terrible to the
> system, and destroy accounts, and any other activity that I have access
> to, but I was giving him notice that I was leaving. What is the professional
> thing to do?
Exactly what you did. The CIO didn't -necessarily- think you were going to do anything. But some guys do, and if they disable access as a matter of routine, their asses are protected better. It is much less of a problem to prevent you from doing any work than to -fail- to prevent the next guy from doing damage.
Don't take it personally, unless you have heard specific comments on your character or performance.
> I submitted a letter of resignation yesterday, and today I'm at home posting
> stories to my weblog and Slashdot.
Well, the blogging and SlashDot part might make employers nervous. You might consider waiting to post, just to avoid letting something slip through without careful thought.
I just make it a policy not to talk too much about jobs and employers after I've left. If you don't say anything, you can't say anything by mistake.
> I gave my employer two weeks notice, and almost immediately, I had my
> accounts disabled, and my permissions revoked on all the computers at my
> work, which makes me unable to do anything in my position of being a
> 'Systems Analyst/Systems Administrator'.
Not necessarily. Often, I've used the period between notice and actually leaving to write documentation, follow up in person with others, giving them information they should have and answering questions. You can still work, you just need to change the focus from "what I usually do" to "what I can and must do to transition."
> I spoke with the HR rep, and gave her my notice yesterday, then I spoke with
> her today about what had happened to my access, and they honored my
> resignation... 2 weeks early. (Luckily, I'm compensated in pay for the next
> two weeks).
Sometimes that's the best. But truly, in many cases the next step after filing the letter of resignation is to be escorted off the premises by security. Again, no reflection on you; it's just SOP.
> isn't it a bit brain damaged to ship something on 7 CDs?
> That's like back when we shipped Windows on 15 floppies, when CDs were on the
> fringe of new technology. DVDs could still be considered technologically
> frenge devices, but when every major game console (sans Gamecube *rumble*),
> new PC, and Laptop ships with a dvd player.. well, it's hard to ignore it
> as a publication medium. Those 7 CDs would fit perfectly on a DVD with room
> to spare.
You're right, in the sense that DVD is -much- smaller, and MS has been pestering the developers who subscribe to go to DVD for years. However, the subscriptions aren't set up to select DVD or CD -by product-; it's -all CD- or -all DVD-.
This means that in addition to getting the DotNet development environment on DVD, you'll also get the test platforms (foreign language OS versions and legacy operating systems) on DVD. I waited longer to switch mine over for that reason.
For testing purposes, you often want to use the older hardware, particularly for the foreign language versions. At one firm we had to work with European laptops that were -seriously- underpowered compared to the top of the line Dells we were using in the US.
Having CDs makes it easier for using the older hardware. But at this point, I'd agree that DVD just makes the most sense.
Despite the sarcastic comparisons to Unix, Windows NT has had the capability to update most system components while in use for a long time.
Typically, the user would exit applications before installing, but this is unecessary most of the time.
However, this capability has always required the person writing the installer program to not sabotage this capability by ignoring Microsoft's installation guidelines. Since the refrain from most developers is "what installation guidelines?", problems are frequent in practice.
The article indicates that the primary change is that this "Restart Manager" will discover dependencies at run time, and do the work of shutting down and restarting applications and services (daemons) -in their current state- automatically. It would do nothing for applications that the user can't do now, and nothing for services that can't usually be done by the administrator.
But automating it is nice; I can see where this would be useful.
>> With generally good, but less than perfect accuracy. Wikipedia is not the
>> best source of information on a subject this hotly debated.
> Of course I accept that Wikipedia isn't perfect, but with the greatest
> respect I don't think you can make a case that exit polls aren't:
> i) Used the world over to predict election results, or
> ii) Trusted by the majority of democratic processes as at least a good
> guide to election results.
I didn't. But the wikipedia article referred to went -much- further in its claims. That's why I suggested going to more neutral sources.
> Fact: Exit polls have been trusted...
No argument. But accuracy is always limited by some margin for error. There are known, -real- problems with all traditional polling methods, as the nature of the society we live in is changing. Exit polls are no exception, though they are still -much- more accurate than other polls, and do not suffer from some of the same problems.
> Fact: Since the 2000 presidential election...
No argument, although I am not comfortable with assigning one and only one cause for the inaccuracies. I don't argue that the Diebold machines are -a- cause. I don't even seriously suggest that something else is the primary cause, although I'd listen to an argument someone else made.
My real concern is that in the quest to find the one and only one cause, we patch one hole in a broken system. I'd like to fix -all- the problems.
> Fact: The 2000 and (specifically) 2004 elections favoured a party whose
> popularity was dropping.
Based on what? I'll accept this as a possibility; but I'll want to see details. From my point of view, -both- parties have lost an enormous amount of popularity and credibility. Again, I am not saying "Republican good, Democrat bad"; I'm saying most people I speak to don't think much of either party.
> This is the same party with strong links to the Diebold...
True, but the other party is an enabler, pushing for fast replacement of fundamentally working punch card and OCR systems with untested touch-screen crap in order to get the public -perception- of addressing the problem. Both parties are at fault for the current debacle.
> Fact: The party pushing for a lack of audit-trail...
Again, based on what? What I have seen is officials of both parties at -all- levels being equally obstructive regarding auditing and paper trails. I'm not arguing about the problem; but I haven't seen the white knight on his white horse battling the dark ogres.
>> Many of the inaccuracies cited in Florida and Ohio in particular are not
>> evidence of election tampering as much as evidence of the fact that election
>> jobs are handed out to party hacks who aren't competent to do any real work.
> Granted, it could conceivably be lack of education or training, however:
> Since the 2000 elections there hasn't been a radical change in the training
> processes of exit-pollsters, so the exit polls are unlikely to have suddenly
> become more or less accurate, meaning the election process itself is somehow
> at fault.
Again, I don't disagree that the process is at fault. Simply that the deviations noted are within the tolerances for error -without- a partisan plot. They are higher than they ought to be, and higher than they would be in a working system, but still possible without a conspiracy. With a broken system, it is quite possible for the errors to not cancel each other out.
I'm not even saying there was no tampering; I'm saying there has been tampering with all elections since the process began, by all parties. I'm saying that deviations in statistics and polls are insufficient in and of themselves to take effective action. To fix the problem, we need an audit trail.
Is it suspicious? Hell yes! Is it a smoking gun? Hell no. You basically have a building that burned and a guy who profited on the insurance.
> Exit polls have been used the world over to predict election results for
i s_the_sam.html
> decades. [link to wikipedia snipped]
With generally good, but less than perfect accuracy. Wikipedia is not the best source of information on a subject this hotly debated.
> So we have a single event where the long-working exit polls (which are
> normally accurate) are suddenly and significantly different from the final
> official tally. This could be written off as a statistical fluke, but the
> Diebold and ES&S machines are already suspected of widespread insecurity
> and/or deliberate tampering, and then when it all hits the media the
> administration announces it won't be conducting exit polls any more?
Tha's somewhat oversimplified, There are -without doubt- problems. The immediate leap to deliberate tampering is not the only explanation, especially in light of historical incompetence of election workers. The reality is that finding, training, and supervising the volunteers who do the work is a large task filled with problems.
Many of the inaccuracies cited in Florida and Ohio in particular are not evidence of election tampering as much as evidence of the fact that election jobs are handed out to party hacks who aren't competent to do any real work.
Many pollsters are changing their methodologies to deal with problems that have been affecting accuracy for some time.
> Why, when they've been used for decades without problem, are exit polls
> suddenly considered dangerous or misleading? Apart from, that is, their
> potential to provide an indication of election-tampering?
The problem is that they can only be used to support a -charge- that the election was botched. They can provide no value in determining the cause of inaccuracies, or determining culpability.
To actually audit the elections, we need an audit trail, not a secondary source of information. I'm not arguing against most of your points. You made some good ones. But you let it fall into simple two-valued logic which I feel weakened the value of your post.
A couple of links people might find useful:
http://www.exit-poll.net/faq.html
http://www.mysterypollster.com/main/2004/12/what_
The one at mystery pollster has some nice links to other sources. I found it very informative.
How sure are we that businesses backed off "because of controversy"?
I see assertions in the articles, but no basis offered for the opinions expressed. I wonder if this isn't a case where corporations simply chose to direct the funds to other opportunities. Not "backing off in fear of the massive power of CREATIONISTS", but rather saying "Nah, I think we'd rather back this one..."
My own experience in fundraising suggests that the second is a fairly strong possibility.
> As an attorney I can tell you that lawyers tend to have a better grasp of
> technology than many other professional groups that I come in contact with.
You're probably right, but that doesn't necessarily mean much. The truth is that a little knowledge is a dangerous thing. A lot of people cause worse problems by thinking they know more than they do. Attorneys are not immune to this.
> You have to be pretty smart to get into law school these days and that
> generally translates into a better understanding of current technology.
Can't agree. Make it "better understanding of how to _utilize_ current technology" and I can agree.
> Furthermore, I doubt that Sony's rootkit scheme was unconditionally approved
> by legal...Companies, especially large companies like Sony, are not run by
> attorneys; they're run by professional managers. It's not uncommon for
> managers to end run legal or simply ignore legal advice when it's not what
> they want to hear.
Or accounting advice, or IT advice...
Very true. Most of the really bonehead plays I've seen managers pull in the last several years have been because they -refused- to ask for or accept legal and/or accounting advice.
> 1. Version Control - find a VC system everyone can agree and use it
> religiously, whether for scripts, programs, or even web docs. I've use
> CVS mainly, with a little Perforce, and Subversion is good so I hear.
Also, since the shop has never had an IT department, make sure everyone knows -how- to use an RCS. I had a project a couple of years back where one guy didn't use the RCS. After a few times I badgereed him to check in, we talked and I discovered he didn't really understand version control. So I spent some time teaching him.
> 4. The Brain Book - there's nothing I hate more than starting a new
> job and having to learn all those server names, IP addresses, what I'm
> supposed to have access to, where in the directory tree the stuff I
> works on live, what types of DBs we use and their versions, etc. So I
> developed the Brain Book, where I would write these things down as I
> learned them, to have a point of reference. It's a good idea to do this
> for all your major projects, so as new people come on, they can spend
> less time learning their way around and more time coding.
We do this as part of an orientation package. Server names, standard share points, who is in charge of what, standard test logins to use, etc. Put it in a document, print it out for everyone new.
> 5. Code Review - everybody's coding style is different and sometimes
> they don't mesh well or there are divergent opinions on how a particular
> task should be coded out. Get your programmers together in a room and
> hash things out as a group. It will provide everyone with a say and may
> open up some people's eyes to new ways of doing things.
Very good advice; this also smooths out problems where any convention is just as good as the next, as long as everyone is consistent. Hashing this out as a group prevents cases where 9 people are asked to change the perfectly acceptable way they do things to conform to the lone other guy's ideas.
> Oracle VS SQL Server. Oracle is free for one processor, 2GB of RAM and a
:)
> 4GB database size. It runs on multiple platforms and it's target market
> is for higher end databases. It can mount XML, TAB delimited and other
> files natively as tables. That is very very nice to developers.
I'll have to take your word for that; I don't know anyone who has needed that particular feature. The only apps I've seen that needed to access XML or TAB delimited data as a table have been -very- tiny utilities; VBA macro in an Excel spreadsheet kind of thing.
> SQL Server has the DTS stuff. DTS is very nice for moving data around,
> but not as nice as actually mounting files as tables.
DTS is -very- useful for moving data around. I'm not a DB admin, but I've not seen a DB admin for SQL Server who doesn't use DTS as a key part of his daily work.
> Oracles Enterprise manager is very comparable to Microsoft's,
Except for the crappy install and configuration (under Windows). Oracle's EM (and many of Oracle's tools, actually) are a giant pain to set up and configure properly anytime the installer fails, which is depressingly often. And Oracle dies with crappy error messages if everything isn't just so (but the error messages are still better than the error messages for IBMs CICS gateway drivers; wrong path gave a "Division By Zero error". At least Oracle gave a legitimate "DLL not found")
> Now I find the core difference in Windows and Linux is that most shops
> do a LOT more on one Linux/Unix box than one Windows box. Most Windows
> shops (ours included), have a Windows server for one specific task,
> perhaps two tasks. Most Linux and Unix boxes run many different tasks
> and as such you need far less of them.
Very true. I think this is nearly universal.
> Perhaps this is just the attitude of Windows users to purchase more
> servers because they are "cheap" but I can say that every place I have
> been this is the case.
It also might be related to the fact that configuration changes almost always required a reboot in the past under Windows. That's much easier to manage if you don't have to interrupt more than one core business task with the reboot. Taking down one business application for a reboot is one thing; taking down three unrelated apps that are on the same box is another.
> Most Unix/Linux guys you talk to mention two things, their uptime AND
> the amount of crap that is running on their boxes. Most Windows guys I
> talk to mention the number of servers they manage. So in short this
> needs to be factored in as well. This issue may also come from all the
> DLL hell that has plagued Microsoft for years, or the fact that it was
> difficult to impossible to run different versions of SQL server on the
> same box.
Not just SQL Server. It's historically been -very- difficult, often impossible, to run two separate versions of anything on one Windows box (reliably). The shared DLLs screw that up all too often. It's better now, but there are too many legacy apps out there that don't play well with others.
> Perhaps we should consider the actual damage done. Is the damage so severe and
...give the law a chance to work. It does take a while.
> widespread that someone needs to (essentially) pay with their life?
Considering the actual damage is important. However, the logical leap that imprisonment is essentially paying with their life is only valid to the extent that working for a living is "paying with your life", and working to pay taxes is "paying with your life." It's a phrase geared to obscuring rather than clarifying.
> Is this really a terrible abuse of power?
No, in the sense that this was not part of a "vast and terrible plot." Yes in the sense that the action was illegal and unethical, -and- totally disproportionate. In order to protect "intellectual property" of dubious worth, Sony exposed millions of their customers to potentially devastating damage.
> It didn't take long for the information about the rootkit to become publicly
> available, and those who care decided not to buy any of the Sony CD's.
The fact that the person who drove drunk (Sony) did not cause loss of life (yet) doesn't affect the base punishment for taking an action that is flagrantly irresponsible. It simply means there is no need to add additional charges based on loss of life.
I said "yet" above because of the fact that merely because the rootkit was exposed does not mean all the remediation has been done. In a corporate environment, it make take weeks or months to identify all compromised machines, apply the fixes, and verify the work. It may take even longer to get most of the machines belonging to common users remediated. The cost may still be considerable, and Sony may still turn out to be responsible for severe damage to some systems.
> This sounds more like a company (Sony) made an uninformed decision to
> purchase a bad technology. Microsoft is just as culpible for their
> administrator-rights-for-everyone and allowing autorun by default.
Not quite. Sony made an uninformed decision to purchase a bad technology (1) which compromises other, non-Sony software on user PCs, and (2) installs without adequate notice.
There is a difference between Ford installing a new anti-lock brake technology at the factory, or in a service call based on a recall notice, which may turn out to be crap with bad side-effects, and Best Buy installing a device that modifies the brakes in a Ford while ostensibly upgrading the speakers in the car's audio system.
One is stupid, arguably irresponsible, but with a certain minimal disclosure and expectation that the change might be made. The second is not only irresponsible, it is actionable.
>
Good advice.
> There will also be class action suits filed against the company. This will
> hurt management, as well as the shareholders.
Hopefully, the shareholders won't allow Sony's board to harm the shareholders excessively to protect the managers.
> ...their shirt can't instantly become six billion more shirts, which you can
> give away for free (or sell for next to nothing, like AllofMP3.com does) and
> take away any reason for anybody else to buy one from them.
Correct. Not "instantly."
But designer clothing does in fact get copied, and very quickly. Instead of trying more and more complicated ways to prevent copying, they've altered the business model to maintain their profits, and depend on the law to reign in the worst abusers.
They don't ignore the illegal duplications, anymore than retailers ignore theft. But like retailers, they recognize that a certain amount of theft is a cost of doing business. They don't antagonize all their customers in an ill-conceived plan to reduce shrinkage to $0 (at least most of them don't, yet).
> Selling recorded music is a multi-million dollar industry, the owners of
> which surely don't want to just give up, just because technology has made it
> fantastically easy to rip them off.
Well, part of the problem is that it is a multi-million dollar rip-off, and they don't want to reduce their own excessive profits. I'm not just talking about ripping off the consumer; I'm talking about ripping off the artists, as well.
The recording and motion-picture industries are notorious for "creative accounting" being used to rip off their artists, distributors, partners, -and- consumers. A search for "fraudulent accounting" and "recording industry" turns up a fair list.
One of the key alternative suggestions is based on the idea, "don't try to rip people off." Cut fair deals with artists, distributors, partners, and consumers. There is evidence that this works, on the rare occasions it has been tried.
I don't illegally copy music. But I also don't buy very much. The truth of the matter is that most of it isn't very good, and almost all of it is ridiculously overpriced.
> It's been a while since I've worked on Windows drivers, but I believe
> certification also means that the driver has passed Microsoft's very rigorous
> driver tests.
Yes and no. Microsoft extensively tests certain aspects of the driver, using certain hardware. They don't test all hardware configurations, just typical ones. And they do nothing to certify certain "optional features" of drivers.
HP is notorious for putting crap features in drivers for a lot of their printers, with the result that Microsoft's generic HP printer drivers are usually -much- more stable than the HP supplied ones. They can't always access all the Cool! New! Features!, but they work fine and are generally much more stable.
This is not just true of HP; as others have mentioned, graphics boards are another area where manufacturers pull stupid stunts.
>> It's important to make sure that the major labels realise that while DRM is
>> legal, there are limits to what people will tolerate - and damaging peoples
>> machines is not something that people are going to tolerate.
> It's not simply a question of tolerance or not; some DRM may be "legal", but
> (IANAL) installing a root-kit on someone's machine without notification or
> permission almost certainly isn't.
In other words, DRM is legal, but that does not mean that -everything- that vendors wish to do to protect their content under DRM is legal.
It's like protecting your home. I can set up alarms and locks, I can buy a gun. I -can't- tie a gun to a trap and set it up to kill a criminal who breaks in.
Note: I am a C++ programmer. I didn't read the book, just the review here. Apologies in advance if anyone takes offense.
> The first couple of chapters introduce the reader to portability concepts
> and then to some of the specific portability features of ANSI C and C++
> that are used throughout the rest of the book.
I think enough software is written in languages other than C and C++ that any serious author should put C or C++ in the title when the book is C or C++ specific.
It's not wrong that the author or publisher chose to call the book "Write Portable Code" instead of "Write Portable Code in ANSI C". But it does make me question if the author's knowledge is limited by a single-language bias.
> The last two chapters look at some alternative ways of getting portability.
> Scripting languages are discussed and the pros and cons of each ones
> portability is weighed. Lastly the use of cross-platform libraries and
> toolkits is addressed.
Given that scripting is limited to one chapter, wouldn't it have been better to refer the reader to other works with more detail and value, and only give a paragraph or so? Particularly since the book is not trying to be about portable code in general, but portability in ANSI C, and discusses nothing (AFAIK) about higher-level compiled languages.
The book's about C. Why clutter it with a chapter on Ruby, Python, and JavaScript/ECMAScript and say nothing about Java, Lisp, SmallTalk, etc? Writing a chapter on scripting languages strikes me as gratuitous filler.
And any non-trivial cross-platform C application is likely to use some sort of cross-platform toolkit. So why only a chapter?
> An example: Rule 4 - "Never read or write structures monolithically from or
> to memory. Always read and write structures one element at a time, so that
> endian, alignment, and size differences are factored out."
Writing structures one element at a time is a -minimum- required for portability. It doesn't completely address byte-order issues, variable internal data representations, or data element size issues. It just ensures that structure packing and alignment issues that might change based on compiler flags are covered. But change the compiler or platform and all these issues are still there even if you write the data elements singly. They are all unspecified or incompletely specified in ANSI C.
It's better to design a complete data representation format, including embedded version information, or just use a higher level data store engine.
My concern is that many of the other rules in the book might be similarly too "low-level" and incompletely specified. Rather than teaching inherently better, more portable coding techniques, they might just be teaching how to work around the low-level nature of C.
> The immediate impact of this is to legalize reverse-engineering projects of
...the letter of the law, and the text of this decision, would seem to only
...The licensee/owner distinction that software companies have asserted is
:)
> custom software where the original coder can't or won't produce the source.
Possibly. Certainly it indicates a right to do some degree of reverse engineering, for the purpose of maintaining the utility of software for which you own a license.
This doesn't necessarily mean you have the right to reverse-engineer software for the purpose of extending it's use.
>
> permit me to use a disassembler to examine the code and fix bugs.
Possibly. I would argue that maintaining utility might involve more than bug-fixing.
The decision text: "Section 117(a)(1) provides an affirmative defense against copyright infringement for anyone who...makes an adaptation 'as an essential step in the utilization of the computer program in conjunction with a machine,' and (iii) uses it 'in no other manner.'
This would tend to indicate that making some adaptations to allow a Windows program to run, for instance, under Wine, might be permitted. Maybe.
> Where this is interesting is that it appears to overrule the software
> industry's assertion that you and I are licenseholders, not owners.
Certainly this indicates that the court feels we own -something- tangible, beyond a license for limited use.
>
> intended to prevent the creation of a used software market.
Well, that is one part of it. Most of the EULAs that specify license don't try to restrict resale, unless the resale is prohibited as part of an upgrade deal.
> EULAs typically include language that prohibits you from selling the software
> "license" to anyone else without getting permission from the vendor first, or
> otherwise jumping through hoops.
I'm not sure that's true. I've seen such clauses, but I don't agree they are 'typical'
> Various vendor "authentication" programs that tie serialized CDs to the MAC
> addresses of your computer essentially do the same thing--you have to get
> permission from Microsoft to subsequently "unlock" that software and install
> it on a different PC.
If that were the sole and only purpose, then you'd be right. In fact, Microsoft's authentication expressly permits resale, and reauthentication is basically the same as always.
From Microsoft's Office 2000 EULA, but it's typical of all of them:
"Software Transfer. The initial licensee of the SOFTWARE PRODUCT may make a one-time permanent transfer of this EULA and SOFTWARE PRODUCT only directly to an end user. This transfer must include all of the SOFTWARE PRODUCT (including all component parts, the media and printed materials, any upgrades, this EULA, and, if applicable, the Certificate of Authenticity). Such transfer may not be by way of consignment or any other indirect transfer. The transferee of such one-time transfer must agree to comply with the terms of this EULA, including the obligation not to further transfer this EULA and SOFTWARE PRODUCT."
By limiting it to transfers direct to the end user, it does limit second-hand sales, but you could get around this by using a third-part that doesn't get too close to the transfer, like eBay.
> You may reasonably conclude that software industry lawyers are going to be
> working overtime on this.
Agreed
> They tried to create a feature that the software did not support,
/. The users of the product knew better.
...the guy who ran [Multidata] was insane...
> and they did so in a manner that broke the software.
> It's not a software bug, it's a user error. This isn't a bug any more than
> it's a "bug" that your Linux box stops working properly if you do sudo rm
> -rf
True. The problem is more that the software spec allowed this misuse and that it triggered a quietly lethal failure. It's a bad failure mode for medical device control software.
>
That's interesting. Any details?
>> You are assuming tight, correct specs - a genuine rarity.
> There are formal languages for specifications (so you can be precise and not
> rely on an English language "description" of what is required), and those
> formal languages are amenable to analysis. In practice just sitting down and
> formalising requirements into this language goes a very long way toward
> determining where ambiguities lie, and which parts need to be checked with
> the client to be certain you've captured the requirement correctly.
Exactly correct. But the fact that this does not happen is in part driven by how businesses create these kinds of products. I've been offered -many- opportunities to design similar, life-in-the-balance medical software. The only reason I didn't take any of them was because -I- knew the kind of qualifications a designer of this kind of thing should have, and I don't have them. But many of these firms just turn around and hire someone who is not even qualified to -know- he isn't qualified.
Businesses offer it not to professional developers of medical software, but to people who have used a cool programming language or tool that one of their engineers read about in an article in a vendor magazine.
> There's a balancing act though.
Yes, there is a balancing act. But it has to be done cooperatively with the employee. A poor manager tries to impose the proper balance based on his assessment only.
> Person A may not value those weekend hours as highly as person B, but they
> would be very unhappy if they saw that person B got a "better deal".
That's one way of looking at it; not mine. I don't see it as an issue of "valuing [blank] more or less". That may be why I'm so gunshy of managers making these kinds of trade-offs.
It's a matter of the -employee- selecting where and when to make personal life concessions to businesses needs. I'm pretty flexible, especially if given a little notice. But there are some times and areas when I can't be flexible, even if I have some notice.
Managers have to accept that at a certain point, they have to work with the employee to find the best balance for each employee. And yes, they need to be sensitive to the perceptions of other employees. Usually I find it helps if other employees are made aware of the fact that, while "John Doe" isn't coming in on Sundays, he also isn't getting any of their perks, and he's pulling additional hours on other days to help make up for it.
It sounds like you understand this just fine. Far too many managers I've worked with don't.
> 1) Flex time, when appropriate.
1.1) And "flex" means the flexibility to leave early and come in late, not just the flexibility to come in a little late and work -much later-.
> 2) Meeting issues. There are 3 kinds of meetings, in my mind: Meetings that
> are productive and important for me, meetings that are productive and
> important to other people, and meetings where upper management wants to whack
> off in public.
2.1) And have an agenda, given to the participants in advance. If you can't tell people what the meeting is about, you don't understand your purpose well enough to have a meeting.
> 5) Privacy. Or, rather, a lack of frequent interruptions.
5.1) Also, a clear appreciation of personal boundaries is good.
> 6) Little things. The best motivator I ever got came at the end of a 3 week
> crunch...
6.1) Things like that only work if the boss understands the employee. Lots of incentives like that backfire. When in doubt, ask.
> Supervising means getting work to me and letting me know what's expected on
> it.
7.1) Also an accurate picture of the reasons -why- something is needed. Who wants it. And allow the employee to ask questions of people as needed.
> Protecting me means keeping assholes like Phil in business development from
> swinging by and talking my ear off for a half hour in the afternoon.
7.2) Or dumping "high-priority" bullshit tasks on my desk at 4 PM when I have other concerns.
> It means not scheduling me for meetings that are a complete and absolute
> waste of my time.
7.3) Or planning to use me in a meeting to support your "cool idea" that I already said won't work. If I already told you 2 * 12 = 24, don't walk into a meeting, tell management that 2 * 12 = 16, turn to me and ask, "Isn't that right?"
I really don't want to make you look like a horse's ass; please do me the same courtesy.
> This is true, but if a valid concern about his opinion comes up, he should be
> able to defend it.
He should be able to defend it in a fair forum. A lot of times, I've been in situations where I was called into an "impromptu" meeting, to justify my recommendation, which is in line with every piece of serious literature in the industry.
It always boiled down to:
- We decided to to A, in B months and for C dollars
- You told us that that won't work, and showed us numbers demonstrating this
when the same thing was tried at ABC and DEF corp
- You suggested doing D in B*2 months and for C/2 dollars, with phased
implementation to reduce risk
- We found a guy who was at DEF corp who said it woulda worked if they had
used DotNet
- Prove DotNet won't work, given that we just disregarded all the literature,
your opinion, and added a speculative measure. Oh, and all your fellow
employees have been coached to give the answer management wants to hear
I've seen firms lose millions this way.
> A lot of it is in approach.
Agreed.
> You can usually legitimately get away with something like; "Someone suggested
> (x) as an alternative to your plan. I'm curious if you have any thoughts on
> the idea." If need be, make sure they understand that their idea is still the
> official plan, and you're looking for clarification rather than a defence.
My only objection is that "get away with" implies bad things for some non-technical managers.
> Don't be a dick.
If you stop right there, it's still the best advice you can give to managers.
> Be honest. Most geeks would perfer if you told them what was going on. Don't
> lie to them unless you 100% have to.
I'd say it a little stronger: "Don't lie to them." You can avoiding telling them things, and couch the truth carefully. But if you think you need to tell a flat-out lie, remember this: you don't get to decide if people find out you lied later. That can happen whether or not you ever intend for the truth to come out. If people find out you lied, you will have lost a very important part of the relationship that lets you manage them effectively.
> Listen to them. If they say "we need a week" then go "including delays and
> testing?". If they say yes then give them 8 days...
Also make sure they haven't already adjusted their estimate downward to make it more palatable. Sometimes they'll say, "we need a week" when they really need a month.
> Remember they're people. If you're getting a drink offer to get them one,
> same goes for if you're making a run some where.
This used to be known as "common courtesy."
> Act like you're one of them because that way you're a friend and not "the
> boss".
If it's an act, then it won't work. Don't act. -Be- a person, just like them.
> Having been employee, manager, and business owner at various times in my
> career, I use the model that 40/week for a paycheck is the base deal. If one
> side wants something more, then they have to offer more in exchange.
> For example, if I'm in a job that offers me nothing more than a paycheck, I
> would regard my boss asking me to work extra hours for any other reason than
> me screwing up as *exactly* equivalent to me saying to him "mind if I go
> take a few hundred from the petty cash tin?" Or: "You want me to work
> weekends? Then I get to telecommute when I don't need to be in for meetings."
> When I was a manager I had the rule that "slack is a medium of exchange".
> Quiet times, everyone got off at lunchtime on Friday and went down the pub.
> Crunch times, we pulled crunch hours - and people were happy with that,
> because they accepted it as part of the trade.
That only works properly with an intelligent manager. For example, I don't drink, and I'm not a twenty-something. I've got a full life outside of work. The boss has to understand that taking off at lunchtime to go to the pub is something that most people are cool with, not a universally acceptable trade-off for extra hours.
Also, there is a difference between asking a young guy to come in for a full day on Sunday, when he would otherwise be watching a game in a bar or playing with a frisbee in the park, and asking an older guy to do the same, when -he- would otherwise be teaching a Sunday School class, or coaching his kid's softball team/
Many managers don't see the difference between "I can't work late late, I have to get to the bar before happy hour ends", and "I can't work late late, I have to drive 25 people to [event]." They respond to both cases with accusations of "not being a team player."
> When one side - employer or employee - acts as if they have a right to more
> than the base deal without offering anything in exchange,
Or unilaterally renogotiate the terms of the agreement significantly, as in 5-day-weeks becoming 7-day-weeks, etc.
> the other side will get very unhappy very fast. Even if circumstances force
> them to give what they're being asked for, the party getting screwed over
> will resent it happening, and that makes life worse for everyone concerned.
And if they can, they will leave.
> As far as the general question of how to manage geeks is concerned, my #1
> rule was: "Happy people work harder."
Miserable managers don't understand happiness. They confuse it with perkiness, or peppyness, or blissful ignorance.
> You can't treat an IT geek the same way you treat a marketing guy. They
> respond to different things.
In the abstract, they respond to the same things. They want the opportunity to affect the quality of their work, and increase the likelihood that their work will have meaning.
Salespeople will leave in droves when management hands them a canned call script and removes their ability to close sales by removing the authority to offer terms and discounts, just as IT people will leave when given a mandate to work without tools.
I've seen cases where management tried to have the salespeople do the initial work only, and leave the closing to the manager. I've never seen it -work-; the salespeople always leave. But I've seen it done.
> The geek wants reassurances that he's doing a good job all of the time,
> especially when things are going smoothly.
As another poster replied, that's horribly oversimplified.
> A marketing guy wants to be adequately rewarded for the big numbers.
The geek and the marketing guy both want to be rewarded. The marketing guy's reward is more direct and tied to something easily quantifiable.
If he's paid an N% commission on sales, he'll react strongly when the boss suddenly declares that the commission is now based on a completely subjective view the boss has of the long-term market growth potential of the sale, and his commissions are cut by 9/10.
The geek is rewarded usually based on the subjective view the boss has of the value of the work done. This is usually completely out-of-touch with the technical merits of the achievements.
So feedback as we go along is more valuable to the geek.
> On my trip Stateside, I was met with nothing but courteousness and friendly
> smiles...On the other hand, many of those I dealt with were mind-bogglingly
> incompetent. Many operated by a fixed set of written rules and were unable
> or unwilling to deal with any situation not dealt with on their crib sheet.
Regrettably, a lot of this is not due to the incompetence of the customer service people, but the incompetence of their superiors.
In many cases, the moronic rules and the "cast-in-stone" nature of them is mandated by managers who are certain they know best.
I recall a time some years ago, in my last "customer service" position, when management decided to change the rules on a particular type of product return. All of us working customer service knew this would piss off our customers. All we asked for is for management to allow us to inform regular customers -before- the change occurred, to ease the transition.
We didn't even want more time, just the chance to tell them prior to beginning the transaction. Management decided this would cause "confusion", and it was mandated as a surprise.
I really got sick of being called a racist white mother-bleeper that first day.
> So between Germany and the US (and from my admittely limited sample space),
> one gets the choice between the devil and the deep blue sea; between
> knowledgeable but lazy and annoying service people, and smiling minimum-wage
> goofballs.
Well, as many people here can attest, a lot of American businesses have tried to use technology to replace the reasonably intelligent service people. On many occasions, I've listened to managers request that our software be so simple they can hire monkeys to do customer service.
You get what you ask for; they wanted monkeys, they got monkeys.