Yes, exactly. Exercise control over the information which in fact you can control.
A useful elaboration on this is to maintain at least one layer of separation between you and the point where your identity is presented to the public. For example, you can maintain a set of email identities that corresponds to the set of social websites in which you participate.
There may be instances where you decide that it's in your interest to override this separation. That's okay, just make it an explicit decision and keep a record of it somewhere.
As a couple of people have mentioned, there is a lot of coolness in the aerospace industry. Flight is awesome, aircraft are beautiful and spacecraft are exotic. There could be aliens out there. Kids are fully plugged into this perspective already, so it makes an excellent hook for engaging almost everyone in the classroom.
Flash some cool pictures, no problem finding those. Talk through them with a few relaxed words about how cool it is that humans made this stuff. Show that there's even more technology inside the aircraft, and on the ground. Talk a bit about how many computers are inside these craft and on the ground. All these complex displays and controls and whatnot, they don't talk to the aircraft, they talk to computers. Computers talk to the aircraft. More pictures, of what things look like with the covers off.
Then you can tell them, this is where I work. Some poetic license is allowed here, I think, for educational purposes. Show pictures of mission control rooms, rows of servers, whatever looks coolest, whatever also conveys the sense that here we have come to the middle of the fortress. Eventually show a picture of yourself in front of a server rack, or working on the servers or something that establishes that this is really where you work.
To my mind, the point is not as some have suggested, to explain how their household computer has some relationship with what you do. Nothing drains coolness away faster than making something appear ordinary. No, you want to let the class know that they're getting a privileged look behind the scenes. It doesn't hurt to talk about security, how hard it is to get into the server room, what responsibility is implied by having root on systems that are used for operations support.
I think these things are totally cool, yet until they're shown, most people wouldn't know to make the connection. Give these kids a chance.
There's no lack of variety in the cell phones on offer. But in my experience, the user interface is far clunkier than it needs to be, even for a modest feature set. I find myself counting the number of key presses required to do frequent or repetitive tasks. These operations could be twice as fast or more with a little more effort on UI design.
And where is the feature set documented? I haven't seen a cell phone in the last five years whose manual actually describes all the features. Since TFA talks about users having problems getting images off the phone, how about this for a suggestion: document how to do it. I bought a new phone last month. It has a camera but no hint anywhere about how to retrieve photos from it. I presume it happens over the mini USB connector, but so far I can't see the filesystem, so evidently it has to be manually enabled somehow.
I don't insist that a big printed manual accompany the phone. But at least give me a small slip of paper with a meaningful URL printed on it. How hard would that be, to have a manual on the net which actually describes available functionality? I can read. I went to school and everything.
And here's another hint. The manual will be a lot easier to write if the UI is clean and consistent in the first place. Come on, it's not rocket science.
My sister-in-law took her car into the shop, asking to have all the warning lights and buzzers deactivated, as they were bothering her.
The service manager was somewhat reluctant to do this, thinking, no doubt, that if he went ahead with the work, it would come back to haunt him. She insisted, reasoning that these things had never happened to her before in all the years she's been driving. Five years later, she's still happy at the thought that she "took charge" of the situation. She likes to tell this story because, to her, it proves that she was right all along.
Sure, I have to agree, at the core it's a matter of priorities. But I think it's one in which simple not-caring has eroded further into not-caring-to-understand. We can laugh a bit inasmuch as it applies to ordinary people, but I find myself alarmed as this almost Orwellian regression from critical thinking into reactivity becomes more fashionable.
That's because it's not just ordinary people but also many trusted individuals who are afflicted. I've lost count of the number of IT managers and network staff who reason anecdotally, who can't seem to distinguish between different subsystems or levels of abstraction, or who don't even consistently apply commonplace notions of causality. These people may be smart and successful, but I find them hard to have as colleagues.
Physicians and car mechanics, on the other hand, seem to have somehow avoided the worst of this erosion. At least, that's what I've observed. I can't explain what, if anything, might set them apart from other technical professionals.
It will never go back to programming for specific pieces of graphical hardware.
I agree with you. Contrast with the article, which seems to be trying to make approximately the same point by overstatement: "Graphics APIs only make sense in the case where you have some very limited, fixed-function hardware underneath the covers."
But of course graphics APIs continue to make sense - in the same way as operating systems continue to make sense - regardless of how rich or lean, slow or fast, or standardized or funky the underlying hardware may be. Last time I checked, there was still tremendous value in being able to offer appropriate and consistent abstractions for expressing algorithms and data, whatever the domain.
Consider the alternative. Taking the article at face value, each application would have to code all its own graphics abstractions in some lowest-common-denominator base language, "a language like C++ or CUDA," as it claims. If you discard the notion of an API, that means you make no provision for a higher-order abstraction above the base language, hence no reusability and no extensibility. That seems pretty retrograde to me.
If, on the other hand, you follow the standard software engineering paradigm, you will have a well defined API with a set of useful base classes and stable functionality for common operations. It will include full access to primitives, which may be the real issue that the article is trying to raise, though it fails to do so. And it will be extensible, so that the API can become richer as techniques evolve.
What's not to like about this? Well, it's not really newsworthy or controversial, is it? It's just software engineering as usual. Ho hum.
In my experience, that works very well, and for exactly the reasons you cited.
It bears mentioning that naming schemes like this are intended for use when we're talking about a particular host in its own right, that is, the primary hostname. A reliable but simple classification scheme is worth more than a complex one that breaks down in edge cases.
Having established a semantically neutral primary hostname, you can then go on to assign secondary names that express the functions served by a particular host. It might turn out that eagle, hawk, and robin should also be called ntp1, ntp2, and ntp3. Then nothing changes except the IP addresses if you decide to move that functionality to another set of hosts. Documentation, and habits of speech, are not instantly obsoleted by deployment changes if you refer to the functional name when talking about the function of a host and the primary name when talking about the host itself.
Kurt Gödel made what, to my mind, is one of history's most exciting and significant contributions to epistemology by way of fundamental computer science. Anyone who graduates with a degree in Computer Science should have been, at least briefly, exposed to his undecidability theorems.
The notation of the original text is quite striking, just cryptic enough to remain mysterious while giving the reader the impression that it can't really be all that hard to figure out what it means.
It is, in a word, art. And it deserves to be on someone's wall.
I've been working as a computer scientist here in Vancouver for thirty years. I've also held a couple of positions in Silicon Valley and Europe.
A couple of people have commented about the importance of sorting out the work visa situation. I'll second that, with emphasis on getting it completed before you enter the country. Most nations, including Canada, you can't apply from within the country. Of course, this creates a Catch 22 in which the strongest justification for issuing the visa comes from having a prospective employer write a letter of offer. And that rarely happens without an interview, or two, or sometimes three, in person. So yeah, it may be necessary to come here for a couple of months ahead of time to do interviews.
I've been trying out recruiters lately. I can recommend a couple, if you want to contact me privately. I can also list several that have, for me at least, proved to be a complete waste of time. Odds are, you can do far better looking on your own. In Vancouver, check out the BC Techlology website: http://www.bctechnology.com/frameset_emp.html
The other comment I'd like to make is that, at least acccording to my experience, there is not much that can be generalized about how employers interview, what they look for, or what you can expect to find after accepting a given position. I think we're generally honest people here in Canada, but it's a young industry in a young culture, and so every organization makes up its own rules and expectations. The interview process is almost entirely directed at finding out about you. Except for a few bare facts, you won't learn much about the organization or the people you'll be working with. What you do learn is designed to make the organization look good, rather than to disclose what sort of challenges and difficulties you can expect from the position. And given the high degree of variability that I mentioned, you really won't know what you've gotten yourself into until the first day on the job. I'm sure this is true the world over, but it has a particular flavor on the west coast of Canada. On one hand, we're bound by Canadian politeness and a mild social reserve that can be hard to break through. On the other hand, we aspire to some form of American entrepreneurialism and the frankness that goes with it. I'm delighted by our West coast liberalism and our tolerance for different cultures, but if I may say so, we're not yet as fully evolved as we think we are. You have an advantage as an Aussie, I think, in that you have lived within a similar cultural paradox. Ours ends up perhaps a bit less tolerant of people being outspoken.
Linux is potentially as vulnerable as other operating systems.
Here you've made one of those foggy claims that sound authoritative but carry essentially zero meaning. Let's put the discussion on a more solid footing.
It's unlikely, under any meaningful measure, that Linux is exactly as vulnerable as any other operating system, and of course it's nonsense to suggest that its vulnerability would change with popularity. Not that you said that, but it happens that many people drag that red herring along right about now, so let's dispense with it too.
On an architectural basis, you could claim that the degree of vulnerability of a given Linux distro will be similar to other Linux distros or other Unix variants, and you could point to what set of design decisions contribute to the relative strength or weakness of these classes of systems in general. That's a very useful and clarifying basis for debate.
Or you could compare a specific point of design or implementation between two different systems. But it's meaningless to just wave your hands and claim that one entire system is or isn't "more secure" than the other, without establishing the terms of reference. For example, a system which allows "default permit" to operations such as software installation, or which fails to separate privilege, is less secure with respect to these design principles than one which enforces privilege separation and "default deny" on operations which might compromise security.
Another approach is to look at incident statistics. Normalized per unit of a given operating system in the field, how do systems rank in terms of actual compromise? To date, Linux ranks below OpenBSD but vastly above Microsoft Windows.
I agree with your point that you can't just sit on your hands and expect any given system to be invulnerable. You have to be vigilant. It doesn't follow that all systems are therefore created equal.
I don't think they're going to be able to get people who actually understand the risks of the Internet to teach these classes.
You're probably right, but it's a significant event just the same. It's the first step in treating the public interest.
For the past ten years I've been only-half-jokingly advocating for an Internet usage license. Substantially, this would be a way to educate about security. It would be nice if it also makes people less vulnerable themselves when they go on the net, though I wouldn't presume to impose my idea of their safety on them. I think that's the weakness you've pointed out in the approach of teaching people how to protect themselves. It will be like Guidance class in high school. I don't know about you, but it took me a lot of recreational drugs to get through the tedium of those classes.
But licensing, on the other hand, I think is a proper starting point to assure that other users of the net, and the network infrastructure itself, are protected. It's a way of reducing risk to others. What does a driver's license do? It unfortunately doesn't guarantee that all drivers on the road are courteous and competent, though it raises the baseline. However, it does allow us to presume that drivers are responsible for a certain body of knowledge. That premise in turn allows us to create a legal framework for identifying drivers, ticketing offenses, assigning liability, transferring vehicle ownership, and entering into insurance agreements. You don't tie up the courts with arguments that split hairs about what you knew and didn't know. Your license stands as proof that you do know, from having passed both a written exam and a road test.
As Bruce Schneier points out, it's the insurance industry in particular which will raise the profile of information security and drive improvements to both software and user behavior. You'll notice that it's not possible to insure a vehicle for use on public roads by an unlicensed driver. I expect that the equivalent, eventually, will be true on the net. It's too high a risk. Nobody wants to insure it. But once network users are licensed and can be presumed to know what they're doing, those become managed risks, and insurers will compete for your business.
On the other main risk front, do you want to use an operating system that's prone to viruses? Sure, we've got a policy which covers specified perils. It would be cheaper to use a more secure system, but we'll cover a higher risk for a higher fee. That gives vendors a strong incentive to be concerned about security. If a system cannot be operated securely at the level of skill established for a licensed user, the vendor takes the heat.
Jim Prentice was also the one who was recently pushing a highly restrictive copyright bill.
The bill has been quietly sidelined following substantial protest. Of course, it may resurface. The price of freedom is eternal vigilance.
So, two things to conclude: (1) to his detriment, Prentice as a public servant will attempt to advance the interests of industry groups against public interest, and (2) somewhat to his credit, he is able to back down quickly under public pressure. Keep up the pressure.
It's really not a hard concept. You don't, for example, expect people in the aircraft industry to just make up their own processes for maintaining an airframe the way they like it, or supplying their own tools and spare parts for the purpose. You don't see employees at an oil refinery or a nuclear reactor just sort of reinstall their own process control systems when they come on shift. You don't see hospitals encouraging surgeons to autoclave their instruments however they like.
Why is that, do you suppose? Employers could download the responsibility onto individual employees. But they don't.
I don't claim to have the definitive answer, but I might observe that, in most industries, doing things randomly is risky. Specifically, it's risky for the employer. So, rather than suffering an exodus of customers, or massive litigation, or the inconvenience of part of the neighborhood just blowing up, employers generally define the processes and supply the infrastructure necessary. It's generally a more effective way of causing predictable outcomes than just letting people randomly do stuff.
I don't know where the perception arose that it might be a good idea to make a special exception just for computing infrastructure. Just give everybody root? It probably came from the same software vendor who used to assure us that because its customers don't consider security important, security itself must not be important. Except that it always was important, and now it's time to wake up.
It's funny that there is this tendency to propose solutions before we've had much in the way of agreement on the requirements.
I expect that any device I'm going to carry with me everywhere should be primarily about portability. The smaller, lighter, cheaper, more long running, more reliable, the better. Oh, and cheaper, because I don't want to spend my life worrying about it. That means let's get rid of any features which are not strictly to the point.
Primarily, this device is my personal gateway to the net for wherever I happen to be. So it should support robust three-factor authentication. It should interoperate reliably and securely with any local user interfaces within its range, so that its necessarily small size is not a barrier to usability. This means that the interface peripherals must themselves be hardened against tampering, must authenticate to the device, and there must be strong legal sanctions against data capture through keystroke logging, screen scraping, and so on. These are not properties of the device itself, but worth noting because they help to enable it.
Of course it needs some amount of local storage as a cache against periods of low network bandwidth or high cost of use. I don't suppose there's any point in defining ahead of time what exact amount this should be, but as things stand today I agree, 20 gig seems fine. The number serves to illustrate that it's not all about local storage or local capability. Why would it be? Apart from the coherency issues, I'm not going to organize critical data around a device that could easily be lost or damaged. That sort of data should be stored on reliable servers. Same with massive compute power. I'll get it when I need it.
The kind of device worth carrying around is the kind that delivers real telepresent identity. Everything that falls short of that is a stepping stone, or more like a millstone. Touch screens in 2015? Terabytes of storage? That's pathetic.
The way I see it, Microsoft has never, throughout its history, let principled engineering get in the way of its corporate mission. This whole integration thing isn't just something that got pulled out during the anti-trust hearings, it arose through a tendency to cut corners during software design. Modular design is harder, so why do it if the customer doesn't ask for it? Oh, and hey, it helps to exclude competition too.
Then, when the hearings came along, it was convenient to use it as a defense against unbundling. Microsoft later tried to spin that into a feature, you know, like how integrated circuits are really cool, though it really just caused more embarrassment. Remember Scott McNealy saying,
"We are integratable, not integrated. You will never see a Sun employee under oath say that it's so wedged together that you couldn't take out a piece."
Modular design is great. That's why it's a basic design principle. If you don't pay attention to modularity, you end up with a bloated mess. As Microsoft has so amply demonstrated, Vista being just the latest example, you can't add modularity to a design.
But now we're talking not just about a few questionable design decisions but a comprehensive, sustained pattern of behavior, around which an entire corporate culture has formed. It would be great if Microsoft made a suite of products that were cleanly modular and which interoperated well with competing products. This isn't a legal dodge but simply a way of doing business in the wider world. If Microsoft ever establishes a reputation for excellent interoperability and standards compliance, I'll definitely consider buying its products. But it hasn't happened yet, and I'm not holding my breath.
The question should be more along the lines of, "What is the problem with your process that you are allowing these users to install unapproved software?"
Exactly. The essence of dysfunction is to set up a situation that is inherently brittle, and then blame whoever bumps into it and breaks it.
Organizations do not have to be dysfunctional. But face it, some are. And if you find yourself working in one of these, as with any relationship your possible choices are to either tolerate it, leave it, or fix it.
In a properly functioning organization, on the other hand, things are set up so that people have the best chance to be happy and productive. There are no disasters waiting to happen, just ordinary business risks which are, equivalently, business opportunities.
Employees can be dysfunctional, too. Stealing from the organization, breaking into areas where you're not permitted, doing things that you're not supposed to do: finding that you can do any of these things is not justification for doing them. This seems obvious in principle, but in practice it's an exercise of good manners, in other words, the performance of a social contract that has to be learned somewhere along the way. And apparently not everybody has learned it.
In this light, it's interesting to read the large number of posts in which people are complaining that they can't install the software that they need to do their jobs, or conversely, justifying how they must go ahead and install it, and anyway, the fact that they can is license to do so.
Hey, guess what? That's a great way to participate in making a dysfunctional situation even more dysfunctional. If you like living that way. I don't. I'll go through proper channels to fix the problem, or I'll walk away.
Leopard... spots. Not shorts. Leopards don't typically wear shorts.
Apart from that, your spots -- I mean points -- are entirely valid. In my books, Microsoft has permanently extinguished its right to be given the benefit of the doubt. The degree of bad behavior required to do that is impressive.
I like what you wrote there, as I have a similar background and saw the same general trend happening over that time period. But my interpretation is a bit different. I'll offer it for contrast.
Unix became enormously popular at a time when networked computer hardware was reliable and readily available, but still quite expensive. Software licenses for these systems were comparably expensive. Those economics allowed organizations to justify hiring highly competent staff in order to maximize return on investment. The culture was inherited to some degree from the mainframe culture, driven from the top down, and partly from a research culture, driven by design and engineering principles, to support a reliable multiuser environment with good access controls and other security measures.
Microsoft entered into this environment from the extreme bottom end of the scale. It was all about cheapness. No multiuser model, therefore no access controls, and well, conspicuous neglect of security. One of the tricks, I would say, for creating a perception of affordability was that users were expected to maintain their own systems, a situation which persists at many sites to this day. The real cost of managing these systems, dealing with misconfiguration and security issues and so on, can therefore be hidden, though doing so leads to all sorts of trouble and unrealistic expectations.
As these systems become more complex, the need for more expert system administration becomes greater and more difficult to hide. But these same systems are also becoming cheaper, so the relative cost of system administration goes up and also becomes more difficult to hide.
Compound this with the further complexity and brittleness of retrofitting multiuser security, and there will be plenty of dissatisfaction to share around. I don't envy the users who have to endure these systems and the quality of support that goes with them, nor the staff who have to support them. It's a real shame. Which is why I ended up as an open source guy.
To come back your point about management overvaluing the IT department, I end up thinking that it's a bit like the dilemma we face with valuing a police force that is not as effective as we'd like it to be. This question troubles me greatly. Some police departments, like some IT departments, are frankly dysfunctional. How can we possibly fix them? By tying funding to performance? I think so, but too much funding creates complacency and too little creates despair. From where I stand, IT departments are all too often in the despair zone, and that does nobody good. I wish that I could be as clear about policing. Perhaps someone else can make that point.
Ask the workers or management what would happen if the IT staff all got hit by a bus. If the response is "Oh my God, we'd be so fucked," that's a good IT department.
I recall this point being discussed at USENIX many years ago. Actually, it's the sign of a bad IT department when systems are so incomprehensible and brittle that they require constant attention from staff.
A good IT department runs smoothly and with a minimum of drama. It does not fall apart the minute that staff turn their attention to the important tasks of design and planning.
Ironically, there is very tight coupling between cause and effect in a bad environment, considerable buffering in a good environment. This of course creates a terrible misperception in which senior management may tends not to value or reward or finance good IT management.
His 'spirit' is the actual laws that govern the universe as far as I can tell.
I'm more inclined to think that it's the attitude of humility which might arise as aspects of the universe are revealed.
In terms of the subjective experience, it's not important whether the revelation comes from science or through some other means. As a species, we seem to be wired to yearn for it, and a fair subset of the population gets to experience it, if only in brief glimpses.
But those glimpses have a profound effect on individuals. They come away with the conviction that the universe is bigger than we can imagine it to be. And, well, that's a correct perception, given that we have brains the size of cantaloupes with which to model this very large and complex environment. It makes a refreshing contrast to our common error of going around arrogantly thinking that we've got it all figured out.
But then we do an odd thing. Having just tasted firsthand the revelation of how vast and wondrous this universe really is, we immediately start reducing the experience to something we can model. It would be more appropriate to hold the matter open, completely open. Instead, we typically let it collapse back into whatever cognitive framework we happen to favor.
But if we were obliged to reduce a transcendent experience to some kind of finite model, then I think science produces a much more coherent model than any belief system based on faith. One good thing at least about science, in a spiritual context, is that it provides a constructive common ground for people who want to compare their transcendent experiences. Lacking that common ground, what we would have instead would be a Tower of Babel.
I think this account also explains why nonscientific people can hold on so tightly to their alternate beliefs despite their internal contradictions, lack of falsifiability, and uncertain predictive power. A transcendent experience feels a lot like blind faith, only more so. It exists, compellingly and infinitely, as its own explanation. So when you come back to earth again, it can seem like your blind faith has been vindicated, and you may well hold onto it more tightly and defend it more vigorously thereafter. And, sadly, many traditional religions have learned to exploit this effect.
I agree with how Mary Jo Foley introduces the story, but not perhaps with the conclusion that it necessarily tilts the playing field. In fact, history tells us that it might backfire on Microsoft.
After all, it was the same strategy which the commercial Unix vendors started to try out on their customers beginning back in the 1980s, and which continues to this day. The idea was that each variant is recognizably Unix, but with lots of cool proprietary features that your applications should really use to advantage.
In some sense, this arrangement creates a healthy competitive ecosystem. Bear with me here. You have a common framework which benefits everyone, and then you're free to add value on top of that in a modular way. That much is cool. For example, Sun develops NFS on top of the Unix filesystem model, and other platform vendors turn around and develop their own, more or less interoperable, implementations. More interoperable is better, since anything that encourages the entire space to grow will give every participating vendor a small piece of a growing pie. Modularity and interoperability are preserved, which frees users to choose the best solution for their needs. Technology progresses, and everyone wins.
So what's wrong with this picture? Well, it invites a tragedy of the commons. It's fine to develop technologies which genuinely compete for market share based on merit. In the physical world, we see that all the time, for example innovations in motor sports eventually finding their way into production vehicles. The trouble comes when some greedy vendor gets the bright idea to use a proprietary extension as a means to sabotage the competition instead of competing on merit.
Extensions which deliberately break interoperability cause damage to the growing digital commons. The exact tipping point arises when there is little or no real value in innovation, while there is a correspondingly significant loss of compatibility. To the relatively minor degree that the commercial Unix vendors engaged in this practice, they visibly slowed the growth of the entire market segment. By not collaborating more openly, each fought to preserve its own piece of a pie that was no longer growing.
Despite the ensuing damage to the commons, why is it that Microsoft gets away with its much more radical embrace-and-extend strategy? I'd argue that this is the result only in cases where by doing so it can overwhelm the competition. While it's true that there is not much real innovation, and the pie is therefore not growing nearly as fast as it would under conditions of healthy competition, Microsoft gets essentially all of it. At that point, growth due to adoption gives way to growth of the base population.
But this situation does not so clearly obtain where free software is concerned. The GPL sees to that. Even if an open source application is ported to Windows, there is nothing to stop it being ported back to some other platform. Yes, in principle it could become so heavily integrated with Windows that portability becomes an issue, but this is exactly what hurt commercial Unix vendors in the long run. Given a choice between two similar applications, one which is locked into a proprietary platform, and one which ports easily between multiple platforms, which of the two is most strategically versatile? Which is more capable of being adapted to a broad variety of new capabilities as they become available on diverse platforms?
Slashdot Mirror
What processes are in place to protect users from malicious code?
Exactly the same processes which are used in closed source, plus one more: the ability to inspect the software.
This is why Bruce Schneier says, "Demand open source code for anything related to security."
"Sed quis custodiet ipsos Custodes?"
(But who is to guard the guardians?)
Juvenal, Satires, circa 120 AD
This model of processing is better expressed with events than threads.
For discussion, see Ousterhout, "Why Threads Are A Bad Idea (for most purposes)"
Yes, exactly. Exercise control over the information which in fact you can control.
A useful elaboration on this is to maintain at least one layer of separation between you and the point where your identity is presented to the public. For example, you can maintain a set of email identities that corresponds to the set of social websites in which you participate.
There may be instances where you decide that it's in your interest to override this separation. That's okay, just make it an explicit decision and keep a record of it somewhere.
As a couple of people have mentioned, there is a lot of coolness in the aerospace industry. Flight is awesome, aircraft are beautiful and spacecraft are exotic. There could be aliens out there. Kids are fully plugged into this perspective already, so it makes an excellent hook for engaging almost everyone in the classroom.
Flash some cool pictures, no problem finding those. Talk through them with a few relaxed words about how cool it is that humans made this stuff. Show that there's even more technology inside the aircraft, and on the ground. Talk a bit about how many computers are inside these craft and on the ground. All these complex displays and controls and whatnot, they don't talk to the aircraft, they talk to computers. Computers talk to the aircraft. More pictures, of what things look like with the covers off.
Then you can tell them, this is where I work. Some poetic license is allowed here, I think, for educational purposes. Show pictures of mission control rooms, rows of servers, whatever looks coolest, whatever also conveys the sense that here we have come to the middle of the fortress. Eventually show a picture of yourself in front of a server rack, or working on the servers or something that establishes that this is really where you work.
To my mind, the point is not as some have suggested, to explain how their household computer has some relationship with what you do. Nothing drains coolness away faster than making something appear ordinary. No, you want to let the class know that they're getting a privileged look behind the scenes. It doesn't hurt to talk about security, how hard it is to get into the server room, what responsibility is implied by having root on systems that are used for operations support.
I think these things are totally cool, yet until they're shown, most people wouldn't know to make the connection. Give these kids a chance.
There's no lack of variety in the cell phones on offer. But in my experience, the user interface is far clunkier than it needs to be, even for a modest feature set. I find myself counting the number of key presses required to do frequent or repetitive tasks. These operations could be twice as fast or more with a little more effort on UI design.
And where is the feature set documented? I haven't seen a cell phone in the last five years whose manual actually describes all the features. Since TFA talks about users having problems getting images off the phone, how about this for a suggestion: document how to do it. I bought a new phone last month. It has a camera but no hint anywhere about how to retrieve photos from it. I presume it happens over the mini USB connector, but so far I can't see the filesystem, so evidently it has to be manually enabled somehow.
I don't insist that a big printed manual accompany the phone. But at least give me a small slip of paper with a meaningful URL printed on it. How hard would that be, to have a manual on the net which actually describes available functionality? I can read. I went to school and everything.
And here's another hint. The manual will be a lot easier to write if the UI is clean and consistent in the first place. Come on, it's not rocket science.
My sister-in-law took her car into the shop, asking to have all the warning lights and buzzers deactivated, as they were bothering her.
The service manager was somewhat reluctant to do this, thinking, no doubt, that if he went ahead with the work, it would come back to haunt him. She insisted, reasoning that these things had never happened to her before in all the years she's been driving. Five years later, she's still happy at the thought that she "took charge" of the situation. She likes to tell this story because, to her, it proves that she was right all along.
Sure, I have to agree, at the core it's a matter of priorities. But I think it's one in which simple not-caring has eroded further into not-caring-to-understand. We can laugh a bit inasmuch as it applies to ordinary people, but I find myself alarmed as this almost Orwellian regression from critical thinking into reactivity becomes more fashionable.
That's because it's not just ordinary people but also many trusted individuals who are afflicted. I've lost count of the number of IT managers and network staff who reason anecdotally, who can't seem to distinguish between different subsystems or levels of abstraction, or who don't even consistently apply commonplace notions of causality. These people may be smart and successful, but I find them hard to have as colleagues.
Physicians and car mechanics, on the other hand, seem to have somehow avoided the worst of this erosion. At least, that's what I've observed. I can't explain what, if anything, might set them apart from other technical professionals.
It will never go back to programming for specific pieces of graphical hardware.
I agree with you. Contrast with the article, which seems to be trying to make approximately the same point by overstatement: "Graphics APIs only make sense in the case where you have some very limited, fixed-function hardware underneath the covers."
But of course graphics APIs continue to make sense - in the same way as operating systems continue to make sense - regardless of how rich or lean, slow or fast, or standardized or funky the underlying hardware may be. Last time I checked, there was still tremendous value in being able to offer appropriate and consistent abstractions for expressing algorithms and data, whatever the domain.
Consider the alternative. Taking the article at face value, each application would have to code all its own graphics abstractions in some lowest-common-denominator base language, "a language like C++ or CUDA," as it claims. If you discard the notion of an API, that means you make no provision for a higher-order abstraction above the base language, hence no reusability and no extensibility. That seems pretty retrograde to me.
If, on the other hand, you follow the standard software engineering paradigm, you will have a well defined API with a set of useful base classes and stable functionality for common operations. It will include full access to primitives, which may be the real issue that the article is trying to raise, though it fails to do so. And it will be extensible, so that the API can become richer as techniques evolve.
What's not to like about this? Well, it's not really newsworthy or controversial, is it? It's just software engineering as usual. Ho hum.
It bears mentioning that naming schemes like this are intended for use when we're talking about a particular host in its own right, that is, the primary hostname. A reliable but simple classification scheme is worth more than a complex one that breaks down in edge cases.
Having established a semantically neutral primary hostname, you can then go on to assign secondary names that express the functions served by a particular host. It might turn out that eagle, hawk, and robin should also be called ntp1, ntp2, and ntp3. Then nothing changes except the IP addresses if you decide to move that functionality to another set of hosts. Documentation, and habits of speech, are not instantly obsoleted by deployment changes if you refer to the functional name when talking about the function of a host and the primary name when talking about the host itself.
The notation of the original text is quite striking, just cryptic enough to remain mysterious while giving the reader the impression that it can't really be all that hard to figure out what it means.
It is, in a word, art. And it deserves to be on someone's wall.
A couple of people have commented about the importance of sorting out the work visa situation. I'll second that, with emphasis on getting it completed before you enter the country. Most nations, including Canada, you can't apply from within the country. Of course, this creates a Catch 22 in which the strongest justification for issuing the visa comes from having a prospective employer write a letter of offer. And that rarely happens without an interview, or two, or sometimes three, in person. So yeah, it may be necessary to come here for a couple of months ahead of time to do interviews.
I've been trying out recruiters lately. I can recommend a couple, if you want to contact me privately. I can also list several that have, for me at least, proved to be a complete waste of time. Odds are, you can do far better looking on your own. In Vancouver, check out the BC Techlology website: http://www.bctechnology.com/frameset_emp.html
The other comment I'd like to make is that, at least acccording to my experience, there is not much that can be generalized about how employers interview, what they look for, or what you can expect to find after accepting a given position. I think we're generally honest people here in Canada, but it's a young industry in a young culture, and so every organization makes up its own rules and expectations. The interview process is almost entirely directed at finding out about you. Except for a few bare facts, you won't learn much about the organization or the people you'll be working with. What you do learn is designed to make the organization look good, rather than to disclose what sort of challenges and difficulties you can expect from the position. And given the high degree of variability that I mentioned, you really won't know what you've gotten yourself into until the first day on the job. I'm sure this is true the world over, but it has a particular flavor on the west coast of Canada. On one hand, we're bound by Canadian politeness and a mild social reserve that can be hard to break through. On the other hand, we aspire to some form of American entrepreneurialism and the frankness that goes with it. I'm delighted by our West coast liberalism and our tolerance for different cultures, but if I may say so, we're not yet as fully evolved as we think we are. You have an advantage as an Aussie, I think, in that you have lived within a similar cultural paradox. Ours ends up perhaps a bit less tolerant of people being outspoken.
Here you've made one of those foggy claims that sound authoritative but carry essentially zero meaning. Let's put the discussion on a more solid footing.
It's unlikely, under any meaningful measure, that Linux is exactly as vulnerable as any other operating system, and of course it's nonsense to suggest that its vulnerability would change with popularity. Not that you said that, but it happens that many people drag that red herring along right about now, so let's dispense with it too.
On an architectural basis, you could claim that the degree of vulnerability of a given Linux distro will be similar to other Linux distros or other Unix variants, and you could point to what set of design decisions contribute to the relative strength or weakness of these classes of systems in general. That's a very useful and clarifying basis for debate.
Or you could compare a specific point of design or implementation between two different systems. But it's meaningless to just wave your hands and claim that one entire system is or isn't "more secure" than the other, without establishing the terms of reference. For example, a system which allows "default permit" to operations such as software installation, or which fails to separate privilege, is less secure with respect to these design principles than one which enforces privilege separation and "default deny" on operations which might compromise security.
Another approach is to look at incident statistics. Normalized per unit of a given operating system in the field, how do systems rank in terms of actual compromise? To date, Linux ranks below OpenBSD but vastly above Microsoft Windows.
I agree with your point that you can't just sit on your hands and expect any given system to be invulnerable. You have to be vigilant. It doesn't follow that all systems are therefore created equal.
You're probably right, but it's a significant event just the same. It's the first step in treating the public interest.
For the past ten years I've been only-half-jokingly advocating for an Internet usage license. Substantially, this would be a way to educate about security. It would be nice if it also makes people less vulnerable themselves when they go on the net, though I wouldn't presume to impose my idea of their safety on them. I think that's the weakness you've pointed out in the approach of teaching people how to protect themselves. It will be like Guidance class in high school. I don't know about you, but it took me a lot of recreational drugs to get through the tedium of those classes.
But licensing, on the other hand, I think is a proper starting point to assure that other users of the net, and the network infrastructure itself, are protected. It's a way of reducing risk to others. What does a driver's license do? It unfortunately doesn't guarantee that all drivers on the road are courteous and competent, though it raises the baseline. However, it does allow us to presume that drivers are responsible for a certain body of knowledge. That premise in turn allows us to create a legal framework for identifying drivers, ticketing offenses, assigning liability, transferring vehicle ownership, and entering into insurance agreements. You don't tie up the courts with arguments that split hairs about what you knew and didn't know. Your license stands as proof that you do know, from having passed both a written exam and a road test.
As Bruce Schneier points out, it's the insurance industry in particular which will raise the profile of information security and drive improvements to both software and user behavior. You'll notice that it's not possible to insure a vehicle for use on public roads by an unlicensed driver. I expect that the equivalent, eventually, will be true on the net. It's too high a risk. Nobody wants to insure it. But once network users are licensed and can be presumed to know what they're doing, those become managed risks, and insurers will compete for your business.
On the other main risk front, do you want to use an operating system that's prone to viruses? Sure, we've got a policy which covers specified perils. It would be cheaper to use a more secure system, but we'll cover a higher risk for a higher fee. That gives vendors a strong incentive to be concerned about security. If a system cannot be operated securely at the level of skill established for a licensed user, the vendor takes the heat.
The bill has been quietly sidelined following substantial protest. Of course, it may resurface. The price of freedom is eternal vigilance.
So, two things to conclude: (1) to his detriment, Prentice as a public servant will attempt to advance the interests of industry groups against public interest, and (2) somewhat to his credit, he is able to back down quickly under public pressure. Keep up the pressure.
It's really not a hard concept. You don't, for example, expect people in the aircraft industry to just make up their own processes for maintaining an airframe the way they like it, or supplying their own tools and spare parts for the purpose. You don't see employees at an oil refinery or a nuclear reactor just sort of reinstall their own process control systems when they come on shift. You don't see hospitals encouraging surgeons to autoclave their instruments however they like.
Why is that, do you suppose? Employers could download the responsibility onto individual employees. But they don't. I don't claim to have the definitive answer, but I might observe that, in most industries, doing things randomly is risky. Specifically, it's risky for the employer. So, rather than suffering an exodus of customers, or massive litigation, or the inconvenience of part of the neighborhood just blowing up, employers generally define the processes and supply the infrastructure necessary. It's generally a more effective way of causing predictable outcomes than just letting people randomly do stuff.
I don't know where the perception arose that it might be a good idea to make a special exception just for computing infrastructure. Just give everybody root? It probably came from the same software vendor who used to assure us that because its customers don't consider security important, security itself must not be important. Except that it always was important, and now it's time to wake up.
It's funny that there is this tendency to propose solutions before we've had much in the way of agreement on the requirements.
I expect that any device I'm going to carry with me everywhere should be primarily about portability. The smaller, lighter, cheaper, more long running, more reliable, the better. Oh, and cheaper, because I don't want to spend my life worrying about it. That means let's get rid of any features which are not strictly to the point.
Primarily, this device is my personal gateway to the net for wherever I happen to be. So it should support robust three-factor authentication. It should interoperate reliably and securely with any local user interfaces within its range, so that its necessarily small size is not a barrier to usability. This means that the interface peripherals must themselves be hardened against tampering, must authenticate to the device, and there must be strong legal sanctions against data capture through keystroke logging, screen scraping, and so on. These are not properties of the device itself, but worth noting because they help to enable it.
Of course it needs some amount of local storage as a cache against periods of low network bandwidth or high cost of use. I don't suppose there's any point in defining ahead of time what exact amount this should be, but as things stand today I agree, 20 gig seems fine. The number serves to illustrate that it's not all about local storage or local capability. Why would it be? Apart from the coherency issues, I'm not going to organize critical data around a device that could easily be lost or damaged. That sort of data should be stored on reliable servers. Same with massive compute power. I'll get it when I need it.
The kind of device worth carrying around is the kind that delivers real telepresent identity. Everything that falls short of that is a stepping stone, or more like a millstone. Touch screens in 2015? Terabytes of storage? That's pathetic.
The way I see it, Microsoft has never, throughout its history, let principled engineering get in the way of its corporate mission. This whole integration thing isn't just something that got pulled out during the anti-trust hearings, it arose through a tendency to cut corners during software design. Modular design is harder, so why do it if the customer doesn't ask for it? Oh, and hey, it helps to exclude competition too.
Then, when the hearings came along, it was convenient to use it as a defense against unbundling. Microsoft later tried to spin that into a feature, you know, like how integrated circuits are really cool, though it really just caused more embarrassment. Remember Scott McNealy saying, "We are integratable, not integrated. You will never see a Sun employee under oath say that it's so wedged together that you couldn't take out a piece."
Modular design is great. That's why it's a basic design principle. If you don't pay attention to modularity, you end up with a bloated mess. As Microsoft has so amply demonstrated, Vista being just the latest example, you can't add modularity to a design.
But now we're talking not just about a few questionable design decisions but a comprehensive, sustained pattern of behavior, around which an entire corporate culture has formed. It would be great if Microsoft made a suite of products that were cleanly modular and which interoperated well with competing products. This isn't a legal dodge but simply a way of doing business in the wider world. If Microsoft ever establishes a reputation for excellent interoperability and standards compliance, I'll definitely consider buying its products. But it hasn't happened yet, and I'm not holding my breath.
Exactly. The essence of dysfunction is to set up a situation that is inherently brittle, and then blame whoever bumps into it and breaks it.
Organizations do not have to be dysfunctional. But face it, some are. And if you find yourself working in one of these, as with any relationship your possible choices are to either tolerate it, leave it, or fix it.
In a properly functioning organization, on the other hand, things are set up so that people have the best chance to be happy and productive. There are no disasters waiting to happen, just ordinary business risks which are, equivalently, business opportunities.
Employees can be dysfunctional, too. Stealing from the organization, breaking into areas where you're not permitted, doing things that you're not supposed to do: finding that you can do any of these things is not justification for doing them. This seems obvious in principle, but in practice it's an exercise of good manners, in other words, the performance of a social contract that has to be learned somewhere along the way. And apparently not everybody has learned it.
In this light, it's interesting to read the large number of posts in which people are complaining that they can't install the software that they need to do their jobs, or conversely, justifying how they must go ahead and install it, and anyway, the fact that they can is license to do so.
Hey, guess what? That's a great way to participate in making a dysfunctional situation even more dysfunctional. If you like living that way. I don't. I'll go through proper channels to fix the problem, or I'll walk away.
I reckon any culture that figures out how to to put gin and tonic together has done the world a great favor.
Apart from that, your spots -- I mean points -- are entirely valid. In my books, Microsoft has permanently extinguished its right to be given the benefit of the doubt. The degree of bad behavior required to do that is impressive.
Unix became enormously popular at a time when networked computer hardware was reliable and readily available, but still quite expensive. Software licenses for these systems were comparably expensive. Those economics allowed organizations to justify hiring highly competent staff in order to maximize return on investment. The culture was inherited to some degree from the mainframe culture, driven from the top down, and partly from a research culture, driven by design and engineering principles, to support a reliable multiuser environment with good access controls and other security measures.
Microsoft entered into this environment from the extreme bottom end of the scale. It was all about cheapness. No multiuser model, therefore no access controls, and well, conspicuous neglect of security. One of the tricks, I would say, for creating a perception of affordability was that users were expected to maintain their own systems, a situation which persists at many sites to this day. The real cost of managing these systems, dealing with misconfiguration and security issues and so on, can therefore be hidden, though doing so leads to all sorts of trouble and unrealistic expectations.
As these systems become more complex, the need for more expert system administration becomes greater and more difficult to hide. But these same systems are also becoming cheaper, so the relative cost of system administration goes up and also becomes more difficult to hide.
Compound this with the further complexity and brittleness of retrofitting multiuser security, and there will be plenty of dissatisfaction to share around. I don't envy the users who have to endure these systems and the quality of support that goes with them, nor the staff who have to support them. It's a real shame. Which is why I ended up as an open source guy.
To come back your point about management overvaluing the IT department, I end up thinking that it's a bit like the dilemma we face with valuing a police force that is not as effective as we'd like it to be. This question troubles me greatly. Some police departments, like some IT departments, are frankly dysfunctional. How can we possibly fix them? By tying funding to performance? I think so, but too much funding creates complacency and too little creates despair. From where I stand, IT departments are all too often in the despair zone, and that does nobody good. I wish that I could be as clear about policing. Perhaps someone else can make that point.
I recall this point being discussed at USENIX many years ago. Actually, it's the sign of a bad IT department when systems are so incomprehensible and brittle that they require constant attention from staff.
A good IT department runs smoothly and with a minimum of drama. It does not fall apart the minute that staff turn their attention to the important tasks of design and planning.
Ironically, there is very tight coupling between cause and effect in a bad environment, considerable buffering in a good environment. This of course creates a terrible misperception in which senior management may tends not to value or reward or finance good IT management.
I'm more inclined to think that it's the attitude of humility which might arise as aspects of the universe are revealed.
In terms of the subjective experience, it's not important whether the revelation comes from science or through some other means. As a species, we seem to be wired to yearn for it, and a fair subset of the population gets to experience it, if only in brief glimpses.
But those glimpses have a profound effect on individuals. They come away with the conviction that the universe is bigger than we can imagine it to be. And, well, that's a correct perception, given that we have brains the size of cantaloupes with which to model this very large and complex environment. It makes a refreshing contrast to our common error of going around arrogantly thinking that we've got it all figured out.
But then we do an odd thing. Having just tasted firsthand the revelation of how vast and wondrous this universe really is, we immediately start reducing the experience to something we can model. It would be more appropriate to hold the matter open, completely open. Instead, we typically let it collapse back into whatever cognitive framework we happen to favor.
But if we were obliged to reduce a transcendent experience to some kind of finite model, then I think science produces a much more coherent model than any belief system based on faith. One good thing at least about science, in a spiritual context, is that it provides a constructive common ground for people who want to compare their transcendent experiences. Lacking that common ground, what we would have instead would be a Tower of Babel.
I think this account also explains why nonscientific people can hold on so tightly to their alternate beliefs despite their internal contradictions, lack of falsifiability, and uncertain predictive power. A transcendent experience feels a lot like blind faith, only more so. It exists, compellingly and infinitely, as its own explanation. So when you come back to earth again, it can seem like your blind faith has been vindicated, and you may well hold onto it more tightly and defend it more vigorously thereafter. And, sadly, many traditional religions have learned to exploit this effect.
After all, it was the same strategy which the commercial Unix vendors started to try out on their customers beginning back in the 1980s, and which continues to this day. The idea was that each variant is recognizably Unix, but with lots of cool proprietary features that your applications should really use to advantage.
In some sense, this arrangement creates a healthy competitive ecosystem. Bear with me here. You have a common framework which benefits everyone, and then you're free to add value on top of that in a modular way. That much is cool. For example, Sun develops NFS on top of the Unix filesystem model, and other platform vendors turn around and develop their own, more or less interoperable, implementations. More interoperable is better, since anything that encourages the entire space to grow will give every participating vendor a small piece of a growing pie. Modularity and interoperability are preserved, which frees users to choose the best solution for their needs. Technology progresses, and everyone wins.
So what's wrong with this picture? Well, it invites a tragedy of the commons. It's fine to develop technologies which genuinely compete for market share based on merit. In the physical world, we see that all the time, for example innovations in motor sports eventually finding their way into production vehicles. The trouble comes when some greedy vendor gets the bright idea to use a proprietary extension as a means to sabotage the competition instead of competing on merit.
Extensions which deliberately break interoperability cause damage to the growing digital commons. The exact tipping point arises when there is little or no real value in innovation, while there is a correspondingly significant loss of compatibility. To the relatively minor degree that the commercial Unix vendors engaged in this practice, they visibly slowed the growth of the entire market segment. By not collaborating more openly, each fought to preserve its own piece of a pie that was no longer growing.
Despite the ensuing damage to the commons, why is it that Microsoft gets away with its much more radical embrace-and-extend strategy? I'd argue that this is the result only in cases where by doing so it can overwhelm the competition. While it's true that there is not much real innovation, and the pie is therefore not growing nearly as fast as it would under conditions of healthy competition, Microsoft gets essentially all of it. At that point, growth due to adoption gives way to growth of the base population.
But this situation does not so clearly obtain where free software is concerned. The GPL sees to that. Even if an open source application is ported to Windows, there is nothing to stop it being ported back to some other platform. Yes, in principle it could become so heavily integrated with Windows that portability becomes an issue, but this is exactly what hurt commercial Unix vendors in the long run. Given a choice between two similar applications, one which is locked into a proprietary platform, and one which ports easily between multiple platforms, which of the two is most strategically versatile? Which is more capable of being adapted to a broad variety of new capabilities as they become available on diverse platforms?
And why is that? Because Microsoft can't just make up its own rules. I know it must come as a shock to you, but not to the rest of us.
Poor Microsoft. You make it sound almost like you were disadvantaged in some way.