Calum T. Dalek is the permanent honourary head of Waterloo's CSC. They needed a name to put on the ACM charter, and given that the composition of the CSC changes every four months (ain't co-op grand?) figured that one would do. He is the voice of the CSC. Mr. Mariani served on the executive of the CSC for a few terms during his undergrad career, so the fine dalek is drawing attention to a distinguished alumnus.
There were a few female members in the CSC when I was at Waterloo ('81-'87). Certainly not many, but a few. The CSC was a microcosm of folks fitting within the hacker culture described by esr in The New Hacker's Dictionary. And there were enough women in the math faculty that one CSC member cracked, "It's harder to find a free terminal in this building than a date for Saturday night!".
CSC members without other affiliations weren't as despised as WATSFIC (Waterloo Science Fiction Club) members or mathNEWS editors. But then, the truly cool are always misunderstood, sometimes even by themselves.
Computing is a field that has little tolerance for snobs. As long as your degree is not from a known joke school (and yes, I'll even exclude Wilfrid Laurier University from that category), and you are competent at what you're hired to do, your career prospects are as good as anybody else's.
More important than the school is the type of program. For a junior position I'd prefer to hire someone who has come through a co-op program or done an internship than one who has not.
If you've learned the material, are conversant with some of the literature, can learn beyond the material presented in the classroom, and are willing to keep your ego in check on team projects, you'll do just fine in industry.
The CPCC levy isn't the only reason why private copying via P2P networks is not a legal problem in Canada. There are privacy laws (about which the US has already complained are a hinderance to their terrorist investigations) that prevent the RIAA from issuing subpoenas to Canadian ISPs demanding their logs and subscribers.
This doesn't mean that your file-sharing information is not inaccessible. If you're sharing music, you'll be fine--you're not in violation of Canadian law and practice. If you're sharing kiddy porn or hate literature, the Canadian police can get the data because you're involved in another crime.
If the RIAA was to follow the lead of Canadian direct broadcast satellite providers, they'd make an appeal to morality to address their problem, since the laws here won't help them.
Just in the United States of America. Canada will not grant patents on ways of doing business.
So, set up your e-commerce site on a Canadian host, with a provincial (not federal, so there are no language requirements) numbered company, and Amazon can't touch you.
There were some other neat things in there, but an ordinary screwdriver wouldn't let you see them. The cases were assembled with oval-head screws for that reason. Everyone in Cemcorp had access to the appropriate socket, but not many others did. This was another reason the price was so high--the wedge (only the fileserver, dubbed "Lexicon", was boxy) had to be student-proof.
When you got inside, you found 256, 384, or 512K of RAM, and a piece of non-volatile RAM that stored things like your node ID and initial screen colours. The superuser could reprogram the NVRAM, and superusers had root privileges on all machines on the network, so you could reprogram anybody's NVRAM. I set a sales droid's screen colours to green on purple. When he laughed, and asked for it to come up green on black instead, I obliged, after cycling through black on black on the way.
The Icon did not have to boot from the fileserver. They could be built with a 5.25" floppy drive (the "solo" configuration). The drive controller was very flexible: it could format your floppy with 8, 9, or 10 sectors per track, single- or double-sided. Most floppys for the Icon were formatted to hold 800K; once the DOS emulator was available, it could read and write DOS-formatted floppies without blinking.
There was a speech chip inside. I don't remember the details of the chip, but I do remember it was a bit of an oddball. The speech files had to exist already for it to play back. The software was not available to have it read text off the screen. The only thing I've heard Icons say are Hitch-Hikers' Guide quotes like "Zark off!" and "Share and enjoy!" The default "Hello" grew thin quickly.
The network was a modified Arcnet, running over an oddball co-axial cable (this was the modification). The network had to be terminated at both ends. A lost terminator would hose everybody wanting to use the fileserver (which was everybody). The prototype network repeater was called a "Hortonstat," because it heard "who"s. The prototype could give you an audible alarm if there was a token collision or other network error. It was productized into a smaller, mute, package. With the repeater, you could build networks of 32 nodes (16 had been the previous limit, though we did a network of 25 for the trustees of the Toronto Separate School Board for their internal election of committee members that held together just fine.)
My favourite games were Robot R&D, where you design a robot and a test planet to put the robot through its paces (lots of planets got named Magrathea), and Electric Chemistry Lab, where you could blow things up without getting hurt. But the CGA screen just didn't have the realism, especially after IBM introduced VGA on the PS/2 in 1986.
Cemcorp was a great place for a co-op student to work. The people knew their stuff, knew how to have fun, and wanted to build a cool computer so kids of all ages could do cool stuff. For a few years, they lived that dream. One lasting memory was the response of one of the hardware designers when he was asked what he wanted to see in the Icon 2: "Five 32032s." That would have been a cooler box. But, alas, it wouldn't have run QNX.
The Canadian Broadcorping Castration's Radio 2 network has a 2-hour jazz program called After Hours. Ross Porter, the host, plays a mix of old and new jazz, with occasional features and interviews. Listen for what you like. Porter has also selected tracks for about 4 different compilations, so you can sample from there and shape your collection according to taste.
Unisys didn't build the first ones. A company called Cemcorp (Canadian Educational Microcomputer Corporation) did, using the resources of a couple of other companies. Cemcorp's parent company was a holding company called Meridian Technologies. At the time, Meridian also held MicroDesign (which did the hardware for the Icon, and eventually became part of Cemcorp) and Jutras Die Casting, among other companies. (Now Meridian does only light metal diecasting.) The first two series of Icons were manufactured in Brockville, Ontario, by a company called Microtel.
The processor was the Intel 80186, as an earlier poster noticed. The reason was simple: it was effectively an 8086, and it was available. But with other Canadian companies like Dynalogic/Bytec-Comterm (makers of the Hyperion) wanting 8086s, and Canada being a single distribution region as far as Intel was concerned, there weren't enough 8086s to go around. But nobody else (except the odd controller manufacturer) wanted 80186s. The QNX C compiler had flags to enable '186- and '286-specific instructions, but Cemcorp never used the '186-specific functionality.
The Ontario Ministry of Education provided the seed money for the project. They mandated mostly Canadian content, so QNX was chosen for the operating system. The Waterloo microlanguages, already proven on the Commodore SuperPET were ported for teaching programming, and QNX's own C compiler was included if students wanted to write their own system stuff. It also had a bug-compatibile version of Logo. The Ministry of Education contracted out the development of a graphical shell called Ambience that had three levels of access control: the administrator, teacher, or student. Teachers had access to students' files; the administrator saw everything. There was shared space for showing off good stuff. It was a great concept. But execution was, well, part of the reason the Icon didn't really succeed, because it didn't work like an Apple, and it didn't work like DOS.
So where'd Unisys come in? Well, in 1983 or so when this was getting started (I did co-op stints with Cemcorp from 1984 to 1987), the guys at Cemcorp didn't have the ability to support or market the product. They contracted with Burroughs for support, quality assurance, and marketing. Burroughs and Sperry became Unisys in 1986, and took a greater interest in promoting the Icon, just as the government subsidy was running out. Unisys had taken over all but the design and integration of the product by the time I did my last work term with Cemcorp. With the dropping of government funding, the demand for DOS compatibility, and competition from Apple, the Icon ceased to be viable.
One or two tables, one to three trains per table, one computer per table controlling the trains and switches, and a bunch of machines for developing the code. It'll give the keeners a leg up on the university-level real-time course, perhaps some insight into concurrency, and demonstrate the destructive potential of bugs.
No, I didn't go to MIT. But I am grateful for the influence of their Tech Model Railroad Club.
"Black box" thinking provides the ability to encapsulate or modularise certain functions. You can test the black box to the specification (if the specification is good enough), and determine whether the black box will do its job in the specified context correctly.
Enter "reuse." This can change the context in which the original black box was required to operate. It may work, but it may be degraded in some way (for example, a data management system designed for a year-old HP rp7410 server having to be shoehorned into a five-year-old K460). Or the black box will have to be modified to deal with a new set of conditions (what was a legitimate error in the old context is OK in the new one, and the black box has to have additional input to tell it which context applies). Either of these can be managed.
Things get difficult when this black box is picked up without careful examination and embedded in something completely unknown to the original black box design team. The specification for the black box may not match this new context, and things will break. What's changed? The picture, not the black box. It is not the designers' fault that the black box doesn't fit the new context perfectly. But designers must be prepared to adjust them to new contexts if appropriate. And design managers must be aware of this possibility.
In short, the black box methodology is fine, but it is limited in that it does not recognize changing contexts. Everyone involved in the design process must understand this.
Indeed the "old ways" still work. Canada's federal elections are run by an independent federal agency, not by the individual provinces. This allows for uniformity in the voting and counting process. The ballots are sheets of paper, with the candidates listed in alphabetical order by surname, and the party affiliation (if any) printed below each candidate's name. To the right of each name there is an open circle, where you can make any mark you wish (without mutilating the ballot) as long as it does not identify the voter. If you mismark your ballot, or stick your pencil through it, you can ask for another one from the returning officer, who has to mark the incorrect ballot uncountable (not spoiled; that's a separate category) and set it aside. Blind voters can mark their own ballots, because they get a template that shows them where the circles are on the paper. You have the right to submit an unmarked or spoiled ballot.
When the local poll closes, the deputy returning officer unseals the ballot box, pulls out the ballots one by one, and reads off the name of the candidate the ballot is for. Any scrutineer (candidate-appointed observer) can inspect and challenge any ballot. The ballot is then placed in a pile for that candidate, and challenged ballots are set aside for a judicial inspection and recount if necessary. The votes are tallied by all scrutineers and the poll clerk as they are read, and the counts verified by all observers. Then the sorted piles are counted to validate the tally. Spoiled ballots (unmarked, marked more than once, or identify the voter) get their own tally and pile. Each pile of ballots is placed in an envelope, one for each candidate, the envelopes are sealed, and the seals are signed. Then the envelopes are placed back in the ballot box, which is resealed (with signatures of all scrutineers if they so choose), and returned to the constituency's returning officer for a judicial recount, if required. Once the ballot box has been resealed, the poll's results are phoned in to the candidates' headquarters and the constituency's returning officer. The counting process takes about an hour for each poll. If the consolidated results show a sufficiently narrow margin between the higher-polling candidates, then a full judicial recount is automatic. All the ballot boxes from the constituency are unsealed, the envelopes opened, and the ballots reinspected and recounted by the returning officer and a judge. This, too, is open to scrutiny by the candidates or their agents. (The other candidates may be interested in the recount as well, because it may determine whether they get their nomination fee back for gaining more than 10% of the vote.)
The first public results are announced shortly after the polls close in Newfoundland, Nova Scotia, Prince Edward Island, and New Brunswick. However, under Canadian election law, these results cannot be reported where the polls are open. Thus television and radio coverage is limited to where the polls are closed, and Canadian-based Internet coverage does not begin until the polls close in British Columbia and Yukon. With staggered polling hours across the country, that's usually three hours after the polls close in Atlantic Canada, with enough extrapolation of reported results to declare a winner usually an hour before that, because of the 176 or so (of 301) seats that come from Ontario and Québec. The key is that the projections are made on real vote tallies, not exit polls and demographic profiles. If something is too close to call, the networks and newspapers won't call it. They will wait until they can make a statistically confident decision.
It doesn't make the political analysis any more informed or interesting, though. Usually the analysis boils down to one of "Canadians are grumpy," "Canadians are complacent," or "Ontario doesn't think the way the rest of the country does, but their weight carries the vote."
I may not like the outcome of the process, but that's because I don't usually like the inputs to the process, not the process itself. The process is not completely foolproof, but it is open and verifiable if candidates choose to avail themselves of that openness.
While knowledge of a debugger is useful, it is only a part of the debugging arsenal. You can't beat the wisdom gained by experience.
Some people are better at finding bugs than others. Some people have a broader knowledge of the interactions of various layers of software than others. The more bugs one finds and fixes, the better one gets at finding and fixing them. But move from one environment to another, and only the thought process is portable--you need to re-learn the context (which gets easier the more contexts you've worked in). And sometimes that environment doesn't have the debugger you're most familiar with. So again, the tool itself is devalued, and the ability to "debug outside the box" is emphasised. Sometimes you can't put a debugger on a system (live telephone switch); sometimes you can use a debugger but can't put a debuggable image on (same example--how's your hex and 68x00 assembler?).
In short, a better tool isn't going to make debugging easier. It may shorten the time to identify the problem area, but it doesn't make the process of removing the bug easier, especially in huge systems with many interacting layers and heterogeneous nodes.
That being said, I use stack traces, breakpoints, variable/parameter dumps, and registers when I can get them--and that's about it. The other features don't provide value to me (my opinion, but I'll share without imposing it). Design for debuggability--somebody will feed your software something that's out of spec. Controllable tracing is useful here, but put the control flags in a piece of shared memory that a utility can toggle on and off, because you can't modify environment variables for a running process outside that process. And if your execution environment is guaranteed to have a debugging environment available, master the debugger if you can, but make sure it doesn't master you so you can't debug without it.
The best debugging toolset is, in order of importance, your mind, the source code, the occasional invitation to others to look at the code with you, a whiteboard or notebook, and a room free of distractions. Surface for air and refreshment every 45 minutes or so, and food every few hours (there's a reason the Jargon File has an entry for "rotary debugger"). Debugging software will inform this process, but feature-rich debuggers will not speed it up much.
Work system: it's the only OS family that runs our bug reporting system client (Clarify ClearQuality). Otherwise, it'd be a self-supported Linux system. Corporate standards dictate MSOffice as the app suite, but everything (except for Outlook) now has fairly effective equivalents that run on Linux. The funny thing is that the development environment is actually HP-UX, accessed using Exceed.
Home system: will be all Linux once I migrate the e-mail out of LookOut!, find a suitable genealogy program, and get a high-speed connection to download the stuff that I want to run... I don't have time to replace everything yet. It's dual-bootable to a couple of Linux kernels, but I won't argue for part marks in an all-or-nothing type question.
Wife's laptop: she's got to write papers and I'm not allowed to fiddle with the software until she graduates:-) This restriction is probably a good thing, since the last attitude adjustment her machine got took 30 hours.
From this attitude, any of the distributed computing initiatives like Folding@Home run the risk of being shut down for depriving IBM, HP, Sun, SGI, or even Dell (where the D stands for disposable, but I digress) the opportunity to profit from researchers' computing needs.
Things are severely out of whack when goodwill and generosity are no longer virtues, but obstacles to profit. Society is dead; long live the corporation <grumble>...
Well, they should still make it and not disappoint the people anticipating another B-movie, and to bring production closure to a story everyone can fill in. There are still some surprises that could find their way into the movie.
In retrospect, Lucas could have done what New Line did with The Lord of the Rings trilogy--film them at once, and release them sporadically. But he seems to have wanted the latest and greatest special effects and as many computer-generated characters (they're non-union) as he could get and still keep his second attempt at a triennial release schedule. Now the technology he wanted to exploit has the potential to bite him in the bankroll.
In further retrospect, he really should have done I-III and VII-IX while the theatre was the best place to see the films. But he hadn't figured out where he wanted the stories to go by that time. Oh, well. It's his loss, and a small one in comparison to the huge gains he took on the original trilogy.
Slashdot Mirror
Calum T. Dalek is the permanent honourary head of Waterloo's CSC. They needed a name to put on the ACM charter, and given that the composition of the CSC changes every four months (ain't co-op grand?) figured that one would do. He is the voice of the CSC. Mr. Mariani served on the executive of the CSC for a few terms during his undergrad career, so the fine dalek is drawing attention to a distinguished alumnus.
There were a few female members in the CSC when I was at Waterloo ('81-'87). Certainly not many, but a few. The CSC was a microcosm of folks fitting within the hacker culture described by esr in The New Hacker's Dictionary. And there were enough women in the math faculty that one CSC member cracked, "It's harder to find a free terminal in this building than a date for Saturday night!".
CSC members without other affiliations weren't as despised as WATSFIC (Waterloo Science Fiction Club) members or mathNEWS editors. But then, the truly cool are always misunderstood, sometimes even by themselves.
Computing is a field that has little tolerance for snobs. As long as your degree is not from a known joke school (and yes, I'll even exclude Wilfrid Laurier University from that category), and you are competent at what you're hired to do, your career prospects are as good as anybody else's.
More important than the school is the type of program. For a junior position I'd prefer to hire someone who has come through a co-op program or done an internship than one who has not.
If you've learned the material, are conversant with some of the literature, can learn beyond the material presented in the classroom, and are willing to keep your ego in check on team projects, you'll do just fine in industry.
Apple has posted a security update for both 10.3 and 10.2.8.
The CPCC levy isn't the only reason why private copying via P2P networks is not a legal problem in Canada. There are privacy laws (about which the US has already complained are a hinderance to their terrorist investigations) that prevent the RIAA from issuing subpoenas to Canadian ISPs demanding their logs and subscribers.
This doesn't mean that your file-sharing information is not inaccessible. If you're sharing music, you'll be fine--you're not in violation of Canadian law and practice. If you're sharing kiddy porn or hate literature, the Canadian police can get the data because you're involved in another crime.
The CBC has a brief article and opinion about this.
If the RIAA was to follow the lead of Canadian direct broadcast satellite providers, they'd make an appeal to morality to address their problem, since the laws here won't help them.
Here's Illiad's take from Sunday's User Friendly .
Humour or prescience? I'm not sure, but I love the form number.
Just in the United States of America. Canada will not grant patents on ways of doing business.
So, set up your e-commerce site on a Canadian host, with a provincial (not federal, so there are no language requirements) numbered company, and Amazon can't touch you.
There were some other neat things in there, but an ordinary screwdriver wouldn't let you see them. The cases were assembled with oval-head screws for that reason. Everyone in Cemcorp had access to the appropriate socket, but not many others did. This was another reason the price was so high--the wedge (only the fileserver, dubbed "Lexicon", was boxy) had to be student-proof.
When you got inside, you found 256, 384, or 512K of RAM, and a piece of non-volatile RAM that stored things like your node ID and initial screen colours. The superuser could reprogram the NVRAM, and superusers had root privileges on all machines on the network, so you could reprogram anybody's NVRAM. I set a sales droid's screen colours to green on purple. When he laughed, and asked for it to come up green on black instead, I obliged, after cycling through black on black on the way.
The Icon did not have to boot from the fileserver. They could be built with a 5.25" floppy drive (the "solo" configuration). The drive controller was very flexible: it could format your floppy with 8, 9, or 10 sectors per track, single- or double-sided. Most floppys for the Icon were formatted to hold 800K; once the DOS emulator was available, it could read and write DOS-formatted floppies without blinking.
There was a speech chip inside. I don't remember the details of the chip, but I do remember it was a bit of an oddball. The speech files had to exist already for it to play back. The software was not available to have it read text off the screen. The only thing I've heard Icons say are Hitch-Hikers' Guide quotes like "Zark off!" and "Share and enjoy!" The default "Hello" grew thin quickly.
The network was a modified Arcnet, running over an oddball co-axial cable (this was the modification). The network had to be terminated at both ends. A lost terminator would hose everybody wanting to use the fileserver (which was everybody). The prototype network repeater was called a "Hortonstat," because it heard "who"s. The prototype could give you an audible alarm if there was a token collision or other network error. It was productized into a smaller, mute, package. With the repeater, you could build networks of 32 nodes (16 had been the previous limit, though we did a network of 25 for the trustees of the Toronto Separate School Board for their internal election of committee members that held together just fine.)
My favourite games were Robot R&D, where you design a robot and a test planet to put the robot through its paces (lots of planets got named Magrathea), and Electric Chemistry Lab, where you could blow things up without getting hurt. But the CGA screen just didn't have the realism, especially after IBM introduced VGA on the PS/2 in 1986.
Cemcorp was a great place for a co-op student to work. The people knew their stuff, knew how to have fun, and wanted to build a cool computer so kids of all ages could do cool stuff. For a few years, they lived that dream. One lasting memory was the response of one of the hardware designers when he was asked what he wanted to see in the Icon 2: "Five 32032s." That would have been a cooler box. But, alas, it wouldn't have run QNX.
The Canadian Broadcorping Castration's Radio 2 network has a 2-hour jazz program called After Hours . Ross Porter, the host, plays a mix of old and new jazz, with occasional features and interviews. Listen for what you like. Porter has also selected tracks for about 4 different compilations, so you can sample from there and shape your collection according to taste.
Unisys didn't build the first ones. A company called Cemcorp (Canadian Educational Microcomputer Corporation) did, using the resources of a couple of other companies. Cemcorp's parent company was a holding company called Meridian Technologies. At the time, Meridian also held MicroDesign (which did the hardware for the Icon, and eventually became part of Cemcorp) and Jutras Die Casting, among other companies. (Now Meridian does only light metal diecasting.) The first two series of Icons were manufactured in Brockville, Ontario, by a company called Microtel.
The processor was the Intel 80186, as an earlier poster noticed. The reason was simple: it was effectively an 8086, and it was available. But with other Canadian companies like Dynalogic/Bytec-Comterm (makers of the Hyperion) wanting 8086s, and Canada being a single distribution region as far as Intel was concerned, there weren't enough 8086s to go around. But nobody else (except the odd controller manufacturer) wanted 80186s. The QNX C compiler had flags to enable '186- and '286-specific instructions, but Cemcorp never used the '186-specific functionality.
The Ontario Ministry of Education provided the seed money for the project. They mandated mostly Canadian content, so QNX was chosen for the operating system. The Waterloo microlanguages, already proven on the Commodore SuperPET were ported for teaching programming, and QNX's own C compiler was included if students wanted to write their own system stuff. It also had a bug-compatibile version of Logo. The Ministry of Education contracted out the development of a graphical shell called Ambience that had three levels of access control: the administrator, teacher, or student. Teachers had access to students' files; the administrator saw everything. There was shared space for showing off good stuff. It was a great concept. But execution was, well, part of the reason the Icon didn't really succeed, because it didn't work like an Apple, and it didn't work like DOS.
So where'd Unisys come in? Well, in 1983 or so when this was getting started (I did co-op stints with Cemcorp from 1984 to 1987), the guys at Cemcorp didn't have the ability to support or market the product. They contracted with Burroughs for support, quality assurance, and marketing. Burroughs and Sperry became Unisys in 1986, and took a greater interest in promoting the Icon, just as the government subsidy was running out. Unisys had taken over all but the design and integration of the product by the time I did my last work term with Cemcorp. With the dropping of government funding, the demand for DOS compatibility, and competition from Apple, the Icon ceased to be viable.
One or two tables, one to three trains per table, one computer per table controlling the trains and switches, and a bunch of machines for developing the code. It'll give the keeners a leg up on the university-level real-time course, perhaps some insight into concurrency, and demonstrate the destructive potential of bugs. No, I didn't go to MIT. But I am grateful for the influence of their Tech Model Railroad Club.
"Black box" thinking provides the ability to encapsulate or modularise certain functions. You can test the black box to the specification (if the specification is good enough), and determine whether the black box will do its job in the specified context correctly.
Enter "reuse." This can change the context in which the original black box was required to operate. It may work, but it may be degraded in some way (for example, a data management system designed for a year-old HP rp7410 server having to be shoehorned into a five-year-old K460). Or the black box will have to be modified to deal with a new set of conditions (what was a legitimate error in the old context is OK in the new one, and the black box has to have additional input to tell it which context applies). Either of these can be managed.
Things get difficult when this black box is picked up without careful examination and embedded in something completely unknown to the original black box design team. The specification for the black box may not match this new context, and things will break. What's changed? The picture, not the black box. It is not the designers' fault that the black box doesn't fit the new context perfectly. But designers must be prepared to adjust them to new contexts if appropriate. And design managers must be aware of this possibility.
In short, the black box methodology is fine, but it is limited in that it does not recognize changing contexts. Everyone involved in the design process must understand this.
Indeed the "old ways" still work. Canada's federal elections are run by an independent federal agency, not by the individual provinces. This allows for uniformity in the voting and counting process. The ballots are sheets of paper, with the candidates listed in alphabetical order by surname, and the party affiliation (if any) printed below each candidate's name. To the right of each name there is an open circle, where you can make any mark you wish (without mutilating the ballot) as long as it does not identify the voter. If you mismark your ballot, or stick your pencil through it, you can ask for another one from the returning officer, who has to mark the incorrect ballot uncountable (not spoiled; that's a separate category) and set it aside. Blind voters can mark their own ballots, because they get a template that shows them where the circles are on the paper. You have the right to submit an unmarked or spoiled ballot.
When the local poll closes, the deputy returning officer unseals the ballot box, pulls out the ballots one by one, and reads off the name of the candidate the ballot is for. Any scrutineer (candidate-appointed observer) can inspect and challenge any ballot. The ballot is then placed in a pile for that candidate, and challenged ballots are set aside for a judicial inspection and recount if necessary. The votes are tallied by all scrutineers and the poll clerk as they are read, and the counts verified by all observers. Then the sorted piles are counted to validate the tally. Spoiled ballots (unmarked, marked more than once, or identify the voter) get their own tally and pile. Each pile of ballots is placed in an envelope, one for each candidate, the envelopes are sealed, and the seals are signed. Then the envelopes are placed back in the ballot box, which is resealed (with signatures of all scrutineers if they so choose), and returned to the constituency's returning officer for a judicial recount, if required. Once the ballot box has been resealed, the poll's results are phoned in to the candidates' headquarters and the constituency's returning officer. The counting process takes about an hour for each poll. If the consolidated results show a sufficiently narrow margin between the higher-polling candidates, then a full judicial recount is automatic. All the ballot boxes from the constituency are unsealed, the envelopes opened, and the ballots reinspected and recounted by the returning officer and a judge. This, too, is open to scrutiny by the candidates or their agents. (The other candidates may be interested in the recount as well, because it may determine whether they get their nomination fee back for gaining more than 10% of the vote.)
The first public results are announced shortly after the polls close in Newfoundland, Nova Scotia, Prince Edward Island, and New Brunswick. However, under Canadian election law, these results cannot be reported where the polls are open. Thus television and radio coverage is limited to where the polls are closed, and Canadian-based Internet coverage does not begin until the polls close in British Columbia and Yukon. With staggered polling hours across the country, that's usually three hours after the polls close in Atlantic Canada, with enough extrapolation of reported results to declare a winner usually an hour before that, because of the 176 or so (of 301) seats that come from Ontario and Québec. The key is that the projections are made on real vote tallies, not exit polls and demographic profiles. If something is too close to call, the networks and newspapers won't call it. They will wait until they can make a statistically confident decision.
It doesn't make the political analysis any more informed or interesting, though. Usually the analysis boils down to one of "Canadians are grumpy," "Canadians are complacent," or "Ontario doesn't think the way the rest of the country does, but their weight carries the vote."I may not like the outcome of the process, but that's because I don't usually like the inputs to the process, not the process itself. The process is not completely foolproof, but it is open and verifiable if candidates choose to avail themselves of that openness.
While knowledge of a debugger is useful, it is only a part of the debugging arsenal. You can't beat the wisdom gained by experience. Some people are better at finding bugs than others. Some people have a broader knowledge of the interactions of various layers of software than others. The more bugs one finds and fixes, the better one gets at finding and fixing them. But move from one environment to another, and only the thought process is portable--you need to re-learn the context (which gets easier the more contexts you've worked in). And sometimes that environment doesn't have the debugger you're most familiar with. So again, the tool itself is devalued, and the ability to "debug outside the box" is emphasised. Sometimes you can't put a debugger on a system (live telephone switch); sometimes you can use a debugger but can't put a debuggable image on (same example--how's your hex and 68x00 assembler?). In short, a better tool isn't going to make debugging easier. It may shorten the time to identify the problem area, but it doesn't make the process of removing the bug easier, especially in huge systems with many interacting layers and heterogeneous nodes. That being said, I use stack traces, breakpoints, variable/parameter dumps, and registers when I can get them--and that's about it. The other features don't provide value to me (my opinion, but I'll share without imposing it). Design for debuggability--somebody will feed your software something that's out of spec. Controllable tracing is useful here, but put the control flags in a piece of shared memory that a utility can toggle on and off, because you can't modify environment variables for a running process outside that process. And if your execution environment is guaranteed to have a debugging environment available, master the debugger if you can, but make sure it doesn't master you so you can't debug without it. The best debugging toolset is, in order of importance, your mind, the source code, the occasional invitation to others to look at the code with you, a whiteboard or notebook, and a room free of distractions. Surface for air and refreshment every 45 minutes or so, and food every few hours (there's a reason the Jargon File has an entry for "rotary debugger"). Debugging software will inform this process, but feature-rich debuggers will not speed it up much.
Work system: it's the only OS family that runs our bug reporting system client (Clarify ClearQuality). Otherwise, it'd be a self-supported Linux system. Corporate standards dictate MSOffice as the app suite, but everything (except for Outlook) now has fairly effective equivalents that run on Linux. The funny thing is that the development environment is actually HP-UX, accessed using Exceed.
Home system: will be all Linux once I migrate the e-mail out of LookOut!, find a suitable genealogy program, and get a high-speed connection to download the stuff that I want to run ... I don't have time to replace everything yet. It's dual-bootable to a couple of Linux kernels, but I won't argue for part marks in an all-or-nothing type question.
Wife's laptop: she's got to write papers and I'm not allowed to fiddle with the software until she graduates :-) This restriction is probably a good thing, since the last attitude adjustment her machine got took 30 hours.
From this attitude, any of the distributed computing initiatives like Folding@Home run the risk of being shut down for depriving IBM, HP, Sun, SGI, or even Dell (where the D stands for disposable, but I digress) the opportunity to profit from researchers' computing needs.
Things are severely out of whack when goodwill and generosity are no longer virtues, but obstacles to profit. Society is dead; long live the corporation <grumble> ...
The clipboard has been done already as the CrossPad. It held 50 pages of pen strokes, but didn't require special paper.
Well, they should still make it and not disappoint the people anticipating another B-movie, and to bring production closure to a story everyone can fill in. There are still some surprises that could find their way into the movie.
In retrospect, Lucas could have done what New Line did with The Lord of the Rings trilogy--film them at once, and release them sporadically. But he seems to have wanted the latest and greatest special effects and as many computer-generated characters (they're non-union) as he could get and still keep his second attempt at a triennial release schedule. Now the technology he wanted to exploit has the potential to bite him in the bankroll.
In further retrospect, he really should have done I-III and VII-IX while the theatre was the best place to see the films. But he hadn't figured out where he wanted the stories to go by that time. Oh, well. It's his loss, and a small one in comparison to the huge gains he took on the original trilogy.