The above advice is the best of the lot, in my opinion as a network architect. But you will want to ignore items 4, 5, and 6, since they are not about network design or operations. Instead see item 10. Unless you're agreeing to wear multiple hats, it's not your job to do system administration or application project management. But the rest of the advice is good.
Network engineering can be quite satisfying, not in the creative way of software engineering but in a more deliberative, methodical way. For all that the space of possible solutions in network engineering is surprisingly large, the space of architecturally sound solutions is much more constrained. But you don't know that yet. The above steps will buy you the time you need to figure out the difference. Proceed cautiously. Know where you are before you decide how to move to somewhere else.
I'll recommend one item which I think you'll like as a software developer. Use SNMP. Once you've got item 2 down solid and you know where everything is, you really really want to know what it's doing. That way, if it starts doing something weird, you have a hope of understanding why. So you set up Cacti or MRTG or whatever to poll the devices and maintain historical data, and you graph that data and you keep an eye open for weirdness. The basic metric, of course, is traffic through each interface. You can see how close a given link is to saturation, and under what daily conditions. There are other useful metrics that you'll get around to eventually. I can't believe how many people who call themselves network engineers don't do this. Maybe it's because they don't think programmatically. That's your advantage.
Could be. But it's also because the senior people (eg CIO, CSO) are often operating at a vague, sloppy level of abstraction.
Whether they're acting on their own initiative, or on the advice of technical management - who are themselves often more informed by marketing materials than knowledge of security principles - I'm not surprised to see money being spent on security products without much or any attention to security processes. It's been that way for a long time, though folks like Bruce Schneier will be the first to tell you that's putting the cart before the horse.
What does one of these wonderful "Data Loss Protection" systems actually do? Well, I don't know. It depends. I can tell you what they won't do, and that's do your thinking for you. That's right. Sorry about that. Guess I lost a sale there.
Here we have an industry publication explaining that there is "a whole category of security software designed to keep information from doing things it's not supposed to even inside the firewall." Let me get this straight, because this is the opening sentence of the article. Information does things? It's burning CPU cycles, waiting to break loose and cause havoc? Because I think we're off to a bad start here. I don't think there should be the slightest suggestion that information, which Claude Shannon elegantly defined for us over fifty years ago, does anything at all except exist. Even an algorithm only exists. Some machine ultimately has to do the work which the algorithm specifies, otherwise no work is done.
A more meaningful thing to say is there is data, and data may have structure. Also, there are consumers and producers of data, and they may have structure. In both cases such structure may be divisible above and below a given level of descriptive granularity. (This is an important property to keep in mind, because without it we have no means of analysis.) If we want to talk about a general data management model, that's about all we can say.
Supposing that we want to talk about something more specific, like providing access to some data to some consumers and not others, we have to impose some definitions on both. This is what the CIOs and CSOs actually want. And it's where most of the work lies. Implementation might be hard too, in its own way, in the sense of being laborious and dealing with a lot of inconvenient details of the real workd, but we can't even begin to assess that until we're clear about what we actually want to do. That's the bit that seems to have been forgotten.
The fact is, no product will do your thinking for you. Security is a process. Start by defining what you want to secure, and who are the players. If you haven't done that, there's no point in spending money on security systems.
Many people are taking an arrogant view of these people and there math skills.
Many people are taking an arrogant view of these people and their math skills.
Yet those same people leaving comments live in houses they couldn't afford to buy outright.
Yet those same people leaving comments live in houses which they couldn't afford to buy outright.
They drive cars, they can't afford either.
They drive cars which they can't afford either.
Remember, it only takes one major emergency to help you lose everything.
Remember, it only takes one major emergency to help you loose everything.
(Sorry man, that last one was totally about messing with your mind.)
In all seriousness, I agree with your points. People in general are financially overextended. The reason is partially due to diminishing options and partially to psychology. People overextend financially in order not to appear as if they're overextended financially. It's reflexive, and the marketing machine has become expert at stimulating the reflex.
The machine also encourages people to think that they don't really have to be responsible for the choices they make. The fact is, we're each of us responsible. Let's help each other to avoid the trap.
Very interesting. Not only does it hold for these extreme cases, I wonder if it might offer a clue in our understanding of milder behaviors as well.
In my routine dealings with others, I find myself frustrated at times with the wall of irrationality that I encounter in some people. I don't know if such people would meet the test of being a True Believer, in that they may not have embraced any specific cause. I think it's more that they don't hold evidence and reason to be impartial sources of truth. It's the same mechanism as you describe, but instead of being oriented toward a single cause, it's a general way of thinking about the world.
Because it actively denies evidence and reason, we would in modern terms regard it as a flawed way of thinking about the world. It should be a disadvantage to think this way. Yet it's remarkably tenacious. Within such socially complex animals as human beings, it may be that it's a "good enough" tactic when it comes to brief encounters such as competing for resources. Over the long term, it's parasitic, and not globally optimal, but for the individual it may take a major personal crisis to force a reexamination of a simple tactic that works much of the time and only fails disastrously once in a while.
I don't know where this strange idea comes from that the choice of Ph.D topic is somehow what defines a person's career. It's just a degree requirement, it's not the degree. It provides, as my old friend Bob Woodham used to explain to his grad students, an exercise in depth, not breadth. A Ph.D graduate has demonstrated that he or she knows how to conduct original research, in depth, under formal supervision. In other words, it's a stepping stone. In very rare cases, the research may reveal material of such compelling interest that the student carries on to make the topic a life study. But normally, the student moves on to something else.
I still would not be at all surprised to find prior art.
I wouldn't either. Hash tables with linked lists are in my undergrad notes from 1977. It's in every curriculum, I'm sure.
Oh, yes, the patent also involves garbage collection on the fly. That reminds me, Hans Koomen and I did a implementation of Interlisp right around then too. It had that. I forget where we picked up the algorithm, it was so long ago, but I remember thinking how great it was that the principles had already been developed by the time we needed them.
Those were the days when people were still using rotary-dial telephones, mind you. The patent in question was granted on April 6, 1999.
To summarize: according to the claim, this patent combines two known techniques in what I would regard as an obvious manner. The patent only covers garbage collection on a particular type of data object. Back in the seventies the existing art was already sufficient for managing all data objects.
Indeed, that's the dilemma of technical hiring. As an individual, no matter how talented and qualified you are, and no matter how much of a boom is on, finding interesting work in an ethical workplace is very hard. Employers are notorious for grilling you on your qualifications, not exposing their own operations so that you can ensure that a good fit will result. As an employer, you find that no matter how desperate the state of unemployment, you can't find enough qualified people. You could be receiving 1000 résumés a day for a single position, but the vast majority of them will prove to be duds.
The problem is Canadians employ the metric system, but with US cars calibrated in imperial units, they cannot be allowed on Canadian roads and the cost of conversion is prohibitive.
Dude, it's not April 1st any more.
I live in Vancouver. We see cars with American plates driving around all the time. Trust me, you won't be turned back at the border because your car uses 11/16 spark plugs.
It wouldn't be an impossible issue, except that buildings last a long time. For a period of, let's say, a hundred years, building suppliers would have to carry double the inventory in order to be available in both systems. Construction workers would have to be able to interconvert between dimensions. Imagine calculating the cuts on a hip gable involving a combination of metric and imperial lumber.
At a book sale a few years ago, I picked up an edition of some CMHC construction standards. I got it practically for free, because what it had done was express all dimensioned lumber in metric. A 2x4 was a 51x102, if I remember correctly. This is ridiculous, of course, because a 2x4 expresses nominal dimensions which are useless for calculation. But when the entire industry has a stake in the status quo, what else can you do but say the exact same thing in a different way? Because these dimensions go all the way back to the mill, to the size of planer irons and thread pitches and everything used in the precise manufacture of these materials. Everything changes. Materials, tools, building codes, retraining of dozens of interlocking trades and industries.
At that rate, it would be better to go to a third system in which lumber is coded. In doing so, you could try to approximately line up the reference sizes, so what we now call a 2x4 would be called an A10, say, and there would be an M10 which would be, in fact, 40x90mm or whatever the metric reference called for. I'm just playing with the idea. I don't know if it would work, really. For example, notice that the A10 and M10 sizes are out by a millimetre or two. It would be nice if that were within manufacturing tolerance anyway, but I suppose that's too much to hope in general.
But you do want modularity. In Japan they developed a very nice modular system where a tatami mat measured exactly 3x6 shaku. You would construct entire buildings accordingly, so that the rooms could be tiled by an integer number of these mats. The problem was that the shaku itself wasn't standardized until about a century ago. Your mats were okay in Kyoto but you couldn't take them to Tokyo.
Or maybe Microsoft hates patents as much as any other software company, and the only reason they have such a large portfolio themselves is (rightly) to defend themselves against the likes of Eolas?
That's not a credible explanation. The evidence contradicts it. Microsoft systematically uses patent threat against open source, among other targets. It used OOXML to ensure that document standards would be encumbered by its patents. So clearly it's not the only reason, as you claim it is.
You're also arguing that poor Microsoft has to use patents to protect its inventions? Well, but surely that's what patents are for. It's a legitimate reason, and we can't hold that against Microsoft. On the other hand, it doesn't provide any sort of exoneration. If you look at the record, you can't fail to notice that Microsoft finds itself in court a lot. A lot. Some of that is vexatious litigation, no doubt, but it would be irresponsible for you to suggest those cases are representative. Usually, Microsoft has gotten itself in trouble by cutting things a bit too fine. It earned that reputation by its egregious conduct.
You'd come by and tell me it's impossible for me to support healthcare reform, unless there's some crazy conspiracy.
No, actually, I'd do nothing of the sort. I'd leave the hyperbole to you.
The only plausible reason why Microsoft would go out of its way to reduce patent protections is because the existing "clear and convincing evidence" protection is not in its interest. Given Microsoft's huge patent portfolio, that can only mean that it has greater concern for weakening other patents than it has for protecting its own. Why would that be?
Now we get into speculation. I can imagine two complementary reasons why Microsoft would initiate this course - and remember, Microsoft is not defending itself in court here, it's bringing this action on its own initiative. One reason could be that Microsoft is not producing its own inventions as fast as it could raid others. That's the motive. The other reason is that patents would be more expensive to defend if the law were more ambiguous. Microsoft is big enough to wear out most of its opponents in patent court. That's the means.
CentOS 5.1. It would probably be on FC something or other, except that the system has two video cards, three disk controllers, eight disks and two DVD drives. Turns out to be hard to find a release that supports everything.
Yeah, but that would be strictly a copyright violation, wouldn't it? Surely it's not possible to claim that the appearance of an icon is protected by patent.
I see a lot of responses here from people who seem to have very narrow experience in system administration. Allow me to offer a slightly broader perspective.
It depends.
We don't know the administrative or security policies of this hospital. We don't know its regulatory environment or even what country it's in. We know that it's an "academic hospital", and those of us with experience in academic computing environments know that these tend to be very open both philosophically and in practice.
So, it depends. If there is an established practice of allowing groups within the organization to manage their own facilities, then it's completely appropriate to have done so here. And it's completely inappropriate for staff in the IT department to request access to those facilities, especially after the fact. It's either strictly not their business, or only their business within a mutually agreed SLA. As a senior system administrator, I'd regard that as an attempt by staff to undermine security within the organization. Unfortunately we often deal with junior staff who don't know any better but think they do. That's why I think it's appropriate to take up this issue at a more senior level.
Maybe you'll get your knuckles rapped when you do. It depends on whether there is an established policy that defines how such facilities are to be managed, and whether this particular facility is being managed in line with that policy. On the other hand, if there is no policy, then it's the CIO whose knuckles should be rapped.
One thing I can say for sure is that these scenarios come up all the time. Senior IT people have to anticipate this in formulating policy, and they have to build their networks and train their staff toward the goal of making the organization productive and secure. That's why we all get paycheques. It means obvious things like ensuring that patient treatment and administrative facilities are on their own subnets, behind their own firewalls, with DHCP administered very tightly and switch ports locked down. It many mean the same for individual research labs and other groups, depending on their legitimate needs and budgets. It means having a service catalogue. It means having SLAs. That way, if someone comes along and plugs in a laptop or whatever, it's not the end of the world.
It's possible the guy got in. The evidence he presents is far from conclusive. It's possible he didn't. The operator says there's no evidence for it. Without conclusive evidence, all we can do is idly speculate, which makes this topic perfect for Slashdot.
The way in, apparently, was through a Cisco border router. It only takes a moment to check the router logs. Both successful and failed logins are recorded. Resetting the log leaves evidence. If the site is competently managed, the log events are also sent to a separate syslog host. If I were the site operator and I saw no evidence of incompetent configuration, and nothing amiss in these logs or elsewhere, then I would be comfortable saying, "we have not found evidence of a breach". That, in fact, is what the operator says.
It's a very hard subject for political leaders to name. The United States is permeated with a national identity based on industrialization and empire. And a notable feature of empires is that people within them don't perceive them being empires with the inequity and unsustainability that implies. Look at Britain for a similar example.
How does a political leader speak to this? It's a very unpalatable, almost sacreligious subject, especially if the prevailing culture doesn't value reflection, critical thought, and humility. There are lots and lots of Americans who do, and lots of means for their voices to be heard, but I don't think we're going to hear the subject being broached directly by the political aristocracy.
Barack Obama, to his credit I think, has spoken very thoughtfully and candidly about particular things that are wrong, for example the subprime mortgage debacle and the Wall Street culture which caused it. But it's politically risky for him to make a habot of criticizing the status quo, even if the status quo is in desperate need of being redesigned. The last people to admit it, even to themselves, will be those whose power flows from their position within the status quo.
Tcl was originally conceived as a glue language, that is, a scripting language featuring extensibility via a separate implementation language. For example, Tcl has a package called TLS which adds SSL/TLS capability to the standard socket operations using OpenSSL. With minimal code changes and rapid deployability, your plaintext connection can run over SSL/TLS.
What's especially good about the Tcl approach is that it doesn't reinvent the wheel. The OpenSSL libraries are there already. It's just a matter of providing a framework to access them, and Tcl makes this part easy. Similarly, Tcl is very nice for accessing system facilities, even novel facilities such as might be found in embedded systems, or cell phones, or web browsers for that matter.
In principle, this is no different than JavaScript extensibility. The debate over which is preferable comes down to language design on one hand and interface support on the other. Both are hard to quantify. I find Tcl elegant as a language, JavaScript not. Also, Tcl has a strong support culture which historically has shown excellent consensus when developing new packages. JavaScript extensions seem to be all over the place. Quite possibly that's due to more widespread use, but it results in a more messy ecosystem, which in turn makes broad deployments such as web applications harder to support.
So I think that, if we imagine a Web 3.0 which provides integration over an essentially unbounded variety of mobile devices, the case could be made that Tcl might ultimately win the race over JavaScript. I don't know this. It remains to be seen. But NaCl demonstrates that it's a possibility, at least.
The real problem isn't old computers, it's new software.
It also depends on which software. I'm writing this on a Linux workstation that's 10 years old. It's got a 1.8GHz processor, 512MB of memory. At work, however, I have to use a Windows laptop that's a year old. Processor is 3GHz quad core, memory is 2GB. I find that, on average, I'm twice as productive on the Linux system than on the Windows system. For some tasks, it's more like ten times more productive.
Some of the difference is certainly attributable to bloat and implementation choices. A cold boot in Windows is much slower than in Linux, for example. But I find that most of the difference in productivity, in steady state, is due to differences in design. The design aspect of either platform hasn't significantly changed over the past decade. Linux is still modular, still highly configurable. It's easy for me to set up applications optimally and automate common tasks. Windows is still monolithic, not meaningfully configurable, and impossible to automate. Therefore it's a much less productive environment for professional work. I'm sure it does fine as a consumer system, but that's not what I need.
The point I'm illustrating here is that, in the total equation, hardware performance is a minor issue. Choice of software is what dominates the equation. I'm glad I made the right choice. It's saved me a lot of money in useless hardware upgrades.
It's a hard subject to write about. The article contains some interesting ideas, along with a fair amount of coarse hyperbole which, unfortunately, serves to make it less credible. And nobody who writes professionally should have trouble using words like "effect" and "proscribe" correctly.
The thing is, readers take writing competence as a proxy for competence generally. It's not an unreasonable strategy. Any reader who's not already a subject matter expert is going to have to accept the writer's expertise on faith, at least provisionally, until he has argued his main points. There's no quicker way to undermine that faith than with poor writing, and that's really unfortunate, because there are some good ideas here.
In fact, the issue is not with the SSL/TLS protocol but with the essentially hierarchical characteristics and application of X.509 certificates, and of course with the operation of the human institutions known as Certificate Authorities. It's true that the setup is a bit fishy. We've allowed a situation to develop where foxes have been hired to guard the henhouse, and because of the hierarchical nature of X.509 we're left with no means of correction except to fire all the foxes and start over from scratch. This alone makes a reasonable case for configuring security controls at a finer level of granularity than at the root CAs. But if the argument is going to go anywhere, we need to see some kind of concrete proposal, not just a dismal assessment of the status quo.
If you're intent on securing your message for confidentiality, encrypt it. To secure for integrity, sign it.
This capability has been around since S/MIME (RFC 2630 in 1999.) It applies to content only, so headers are still exposed, and of course there is still no guarantee of delivery, but pretty much every email user today can sign and encrypt their messages if they want to. Standards for header authentication (for example RFC 4408) have not been as widely adopted.
In short, email is an old protocol - one of the earliest, in fact - and it has several shortcomings. But it's not correct to say that "email is inherently insecure."
The bill has a loaded agenda, there's no doubt about that from the examples it cites. But there are many other examples, such as the ones you've listed. This is a science class, right? It can't be a science class if it doesn't apply the methodology of science. But that leaves a pretty wide field. Anything relevant to science education is a legitimate topic.
I'd argue that this sort of political manipulation would backfire in a big way. Studies of political interference, prejudice and bigotry would all make highly relevant topics.
What we should have done was created a GUI which has exact formal one-for-one-correspondence with the underlying CLI
Yes! Someone gets it.
The characteristic advantage of any CLI is that it's a language. We often refer to languages in terms of their clarity and expressive power, much of which comes from composability. For this reason alone, some CLIs end up being much better languages than others. We need to be aware of this because some people will debate the relative advantages of GUIs and CLIs in terms of some particularly nasty instance of a CLI.
Properly, the debate is between language (stream of symbols interpreted explicitly through syntax) and non-language (stream of events interpreted tacitly and differently by each application). It's then quite clear which has the advantage.
Is it possible to build an application which formally couples the GUI and CLI layers? Well, Richard Stallman did it with emacs. And John Osterhout did it with Tcl/Tk. To be clear, these two examples illustrate different aspects of what it means to couple the layers. Because emacs comes preconfigured as a text editor, the binding between GUI and language elements is already made. We can immediately see how it works and begin to extend it. In the case of Tcl/Tk we begin with nothing more than the language interpreter. If we want a GUI, we have to build one. Then it's on us to ensure that a structured relationship exists between the resulting GUI and our functional elements.
On the other hand, Tcl/Tk has native facilities for unit testing. As you develop a GUI application, you also define a test framework that lets you automatically replay the entire suite of identified use cases without having to involve some unhappy and fallible test user to repetitively point and click. It's not that Tcl/Tk is special in any linguistic sense, it's just that this feature is provided natively, and therefore it's ubiquitous.
Not only do languages provide composability and repeatability, they are easy to document. Don't you hate having to document how to use a GUI application to accomplish a particular task? I sure do. First click on this, then select this, then fill in this, then ensure that this checkbox is in some state or other. Gah. It's an agony to write, there is no formal notation to aid the process, it can't be automatically replayed to verify that what you've written is in fact correct, and whether or not you load it full of attractive screen shots, almost none of your intended audience is going to read it anyway.
Documenting a CLI application is much more representative of actually using the application. You can write precisely what is to be done. Formal notations for the documentation metalanguage are widely understood, and in any case can be described in a couple of paragraphs. And, if your particular use of the application is dauntingly complex to describe in this way, you write a script for it, and document how to run that script instead. Try doing that with a GUI.
Slashdot Mirror
The above advice is the best of the lot, in my opinion as a network architect. But you will want to ignore items 4, 5, and 6, since they are not about network design or operations. Instead see item 10. Unless you're agreeing to wear multiple hats, it's not your job to do system administration or application project management. But the rest of the advice is good.
Network engineering can be quite satisfying, not in the creative way of software engineering but in a more deliberative, methodical way. For all that the space of possible solutions in network engineering is surprisingly large, the space of architecturally sound solutions is much more constrained. But you don't know that yet. The above steps will buy you the time you need to figure out the difference. Proceed cautiously. Know where you are before you decide how to move to somewhere else.
I'll recommend one item which I think you'll like as a software developer. Use SNMP. Once you've got item 2 down solid and you know where everything is, you really really want to know what it's doing. That way, if it starts doing something weird, you have a hope of understanding why. So you set up Cacti or MRTG or whatever to poll the devices and maintain historical data, and you graph that data and you keep an eye open for weirdness. The basic metric, of course, is traffic through each interface. You can see how close a given link is to saturation, and under what daily conditions. There are other useful metrics that you'll get around to eventually. I can't believe how many people who call themselves network engineers don't do this. Maybe it's because they don't think programmatically. That's your advantage.
Could be. But it's also because the senior people (eg CIO, CSO) are often operating at a vague, sloppy level of abstraction.
Whether they're acting on their own initiative, or on the advice of technical management - who are themselves often more informed by marketing materials than knowledge of security principles - I'm not surprised to see money being spent on security products without much or any attention to security processes. It's been that way for a long time, though folks like Bruce Schneier will be the first to tell you that's putting the cart before the horse.
What does one of these wonderful "Data Loss Protection" systems actually do? Well, I don't know. It depends. I can tell you what they won't do, and that's do your thinking for you. That's right. Sorry about that. Guess I lost a sale there.
Here we have an industry publication explaining that there is "a whole category of security software designed to keep information from doing things it's not supposed to even inside the firewall." Let me get this straight, because this is the opening sentence of the article. Information does things? It's burning CPU cycles, waiting to break loose and cause havoc? Because I think we're off to a bad start here. I don't think there should be the slightest suggestion that information, which Claude Shannon elegantly defined for us over fifty years ago, does anything at all except exist. Even an algorithm only exists. Some machine ultimately has to do the work which the algorithm specifies, otherwise no work is done.
A more meaningful thing to say is there is data, and data may have structure. Also, there are consumers and producers of data, and they may have structure. In both cases such structure may be divisible above and below a given level of descriptive granularity. (This is an important property to keep in mind, because without it we have no means of analysis.) If we want to talk about a general data management model, that's about all we can say.
Supposing that we want to talk about something more specific, like providing access to some data to some consumers and not others, we have to impose some definitions on both. This is what the CIOs and CSOs actually want. And it's where most of the work lies. Implementation might be hard too, in its own way, in the sense of being laborious and dealing with a lot of inconvenient details of the real workd, but we can't even begin to assess that until we're clear about what we actually want to do. That's the bit that seems to have been forgotten.
The fact is, no product will do your thinking for you. Security is a process. Start by defining what you want to secure, and who are the players. If you haven't done that, there's no point in spending money on security systems.
...until morale improves.
(Sorry man, that last one was totally about messing with your mind.)
In all seriousness, I agree with your points. People in general are financially overextended. The reason is partially due to diminishing options and partially to psychology. People overextend financially in order not to appear as if they're overextended financially. It's reflexive, and the marketing machine has become expert at stimulating the reflex.
The machine also encourages people to think that they don't really have to be responsible for the choices they make. The fact is, we're each of us responsible. Let's help each other to avoid the trap.
Very interesting. Not only does it hold for these extreme cases, I wonder if it might offer a clue in our understanding of milder behaviors as well.
In my routine dealings with others, I find myself frustrated at times with the wall of irrationality that I encounter in some people. I don't know if such people would meet the test of being a True Believer, in that they may not have embraced any specific cause. I think it's more that they don't hold evidence and reason to be impartial sources of truth. It's the same mechanism as you describe, but instead of being oriented toward a single cause, it's a general way of thinking about the world.
Because it actively denies evidence and reason, we would in modern terms regard it as a flawed way of thinking about the world. It should be a disadvantage to think this way. Yet it's remarkably tenacious. Within such socially complex animals as human beings, it may be that it's a "good enough" tactic when it comes to brief encounters such as competing for resources. Over the long term, it's parasitic, and not globally optimal, but for the individual it may take a major personal crisis to force a reexamination of a simple tactic that works much of the time and only fails disastrously once in a while.
"Much like the way no one can force you to visit their website"
Every hyperlink in HTML can potentially force you to a different website than the one serving the current page.
I don't know where this strange idea comes from that the choice of Ph.D topic is somehow what defines a person's career. It's just a degree requirement, it's not the degree. It provides, as my old friend Bob Woodham used to explain to his grad students, an exercise in depth, not breadth. A Ph.D graduate has demonstrated that he or she knows how to conduct original research, in depth, under formal supervision. In other words, it's a stepping stone. In very rare cases, the research may reveal material of such compelling interest that the student carries on to make the topic a life study. But normally, the student moves on to something else.
I still would not be at all surprised to find prior art.
I wouldn't either. Hash tables with linked lists are in my undergrad notes from 1977. It's in every curriculum, I'm sure.
Oh, yes, the patent also involves garbage collection on the fly. That reminds me, Hans Koomen and I did a implementation of Interlisp right around then too. It had that. I forget where we picked up the algorithm, it was so long ago, but I remember thinking how great it was that the principles had already been developed by the time we needed them.
Those were the days when people were still using rotary-dial telephones, mind you. The patent in question was granted on April 6, 1999.
To summarize: according to the claim, this patent combines two known techniques in what I would regard as an obvious manner. The patent only covers garbage collection on a particular type of data object. Back in the seventies the existing art was already sufficient for managing all data objects.
It's not a problem. People do it all the time. Two of my family's cars came into the country that way.
Indeed, that's the dilemma of technical hiring. As an individual, no matter how talented and qualified you are, and no matter how much of a boom is on, finding interesting work in an ethical workplace is very hard. Employers are notorious for grilling you on your qualifications, not exposing their own operations so that you can ensure that a good fit will result. As an employer, you find that no matter how desperate the state of unemployment, you can't find enough qualified people. You could be receiving 1000 résumés a day for a single position, but the vast majority of them will prove to be duds.
The problem is Canadians employ the metric system, but with US cars calibrated in imperial units, they cannot be allowed on Canadian roads and the cost of conversion is prohibitive.
Dude, it's not April 1st any more.
I live in Vancouver. We see cars with American plates driving around all the time. Trust me, you won't be turned back at the border because your car uses 11/16 spark plugs.
It wouldn't be an impossible issue, except that buildings last a long time. For a period of, let's say, a hundred years, building suppliers would have to carry double the inventory in order to be available in both systems. Construction workers would have to be able to interconvert between dimensions. Imagine calculating the cuts on a hip gable involving a combination of metric and imperial lumber.
At a book sale a few years ago, I picked up an edition of some CMHC construction standards. I got it practically for free, because what it had done was express all dimensioned lumber in metric. A 2x4 was a 51x102, if I remember correctly. This is ridiculous, of course, because a 2x4 expresses nominal dimensions which are useless for calculation. But when the entire industry has a stake in the status quo, what else can you do but say the exact same thing in a different way? Because these dimensions go all the way back to the mill, to the size of planer irons and thread pitches and everything used in the precise manufacture of these materials. Everything changes. Materials, tools, building codes, retraining of dozens of interlocking trades and industries.
At that rate, it would be better to go to a third system in which lumber is coded. In doing so, you could try to approximately line up the reference sizes, so what we now call a 2x4 would be called an A10, say, and there would be an M10 which would be, in fact, 40x90mm or whatever the metric reference called for. I'm just playing with the idea. I don't know if it would work, really. For example, notice that the A10 and M10 sizes are out by a millimetre or two. It would be nice if that were within manufacturing tolerance anyway, but I suppose that's too much to hope in general.
But you do want modularity. In Japan they developed a very nice modular system where a tatami mat measured exactly 3x6 shaku. You would construct entire buildings accordingly, so that the rooms could be tiled by an integer number of these mats. The problem was that the shaku itself wasn't standardized until about a century ago. Your mats were okay in Kyoto but you couldn't take them to Tokyo.
Or maybe Microsoft hates patents as much as any other software company, and the only reason they have such a large portfolio themselves is (rightly) to defend themselves against the likes of Eolas?
That's not a credible explanation. The evidence contradicts it. Microsoft systematically uses patent threat against open source, among other targets. It used OOXML to ensure that document standards would be encumbered by its patents. So clearly it's not the only reason, as you claim it is.
You're also arguing that poor Microsoft has to use patents to protect its inventions? Well, but surely that's what patents are for. It's a legitimate reason, and we can't hold that against Microsoft. On the other hand, it doesn't provide any sort of exoneration. If you look at the record, you can't fail to notice that Microsoft finds itself in court a lot. A lot. Some of that is vexatious litigation, no doubt, but it would be irresponsible for you to suggest those cases are representative. Usually, Microsoft has gotten itself in trouble by cutting things a bit too fine. It earned that reputation by its egregious conduct.
You'd come by and tell me it's impossible for me to support healthcare reform, unless there's some crazy conspiracy.
No, actually, I'd do nothing of the sort. I'd leave the hyperbole to you.
The only plausible reason why Microsoft would go out of its way to reduce patent protections is because the existing "clear and convincing evidence" protection is not in its interest. Given Microsoft's huge patent portfolio, that can only mean that it has greater concern for weakening other patents than it has for protecting its own. Why would that be?
Now we get into speculation. I can imagine two complementary reasons why Microsoft would initiate this course - and remember, Microsoft is not defending itself in court here, it's bringing this action on its own initiative. One reason could be that Microsoft is not producing its own inventions as fast as it could raid others. That's the motive. The other reason is that patents would be more expensive to defend if the law were more ambiguous. Microsoft is big enough to wear out most of its opponents in patent court. That's the means.
Stay classy, Microsoft.
CentOS 5.1. It would probably be on FC something or other, except that the system has two video cards, three disk controllers, eight disks and two DVD drives. Turns out to be hard to find a release that supports everything.
Yeah, but that would be strictly a copyright violation, wouldn't it? Surely it's not possible to claim that the appearance of an icon is protected by patent.
I see a lot of responses here from people who seem to have very narrow experience in system administration. Allow me to offer a slightly broader perspective.
It depends.
We don't know the administrative or security policies of this hospital. We don't know its regulatory environment or even what country it's in. We know that it's an "academic hospital", and those of us with experience in academic computing environments know that these tend to be very open both philosophically and in practice.
So, it depends. If there is an established practice of allowing groups within the organization to manage their own facilities, then it's completely appropriate to have done so here. And it's completely inappropriate for staff in the IT department to request access to those facilities, especially after the fact. It's either strictly not their business, or only their business within a mutually agreed SLA. As a senior system administrator, I'd regard that as an attempt by staff to undermine security within the organization. Unfortunately we often deal with junior staff who don't know any better but think they do. That's why I think it's appropriate to take up this issue at a more senior level.
Maybe you'll get your knuckles rapped when you do. It depends on whether there is an established policy that defines how such facilities are to be managed, and whether this particular facility is being managed in line with that policy. On the other hand, if there is no policy, then it's the CIO whose knuckles should be rapped.
One thing I can say for sure is that these scenarios come up all the time. Senior IT people have to anticipate this in formulating policy, and they have to build their networks and train their staff toward the goal of making the organization productive and secure. That's why we all get paycheques. It means obvious things like ensuring that patient treatment and administrative facilities are on their own subnets, behind their own firewalls, with DHCP administered very tightly and switch ports locked down. It many mean the same for individual research labs and other groups, depending on their legitimate needs and budgets. It means having a service catalogue. It means having SLAs. That way, if someone comes along and plugs in a laptop or whatever, it's not the end of the world.
It's possible the guy got in. The evidence he presents is far from conclusive. It's possible he didn't. The operator says there's no evidence for it. Without conclusive evidence, all we can do is idly speculate, which makes this topic perfect for Slashdot.
The way in, apparently, was through a Cisco border router. It only takes a moment to check the router logs. Both successful and failed logins are recorded. Resetting the log leaves evidence. If the site is competently managed, the log events are also sent to a separate syslog host. If I were the site operator and I saw no evidence of incompetent configuration, and nothing amiss in these logs or elsewhere, then I would be comfortable saying, "we have not found evidence of a breach". That, in fact, is what the operator says.
It's a very hard subject for political leaders to name. The United States is permeated with a national identity based on industrialization and empire. And a notable feature of empires is that people within them don't perceive them being empires with the inequity and unsustainability that implies. Look at Britain for a similar example.
How does a political leader speak to this? It's a very unpalatable, almost sacreligious subject, especially if the prevailing culture doesn't value reflection, critical thought, and humility. There are lots and lots of Americans who do, and lots of means for their voices to be heard, but I don't think we're going to hear the subject being broached directly by the political aristocracy.
Barack Obama, to his credit I think, has spoken very thoughtfully and candidly about particular things that are wrong, for example the subprime mortgage debacle and the Wall Street culture which caused it. But it's politically risky for him to make a habot of criticizing the status quo, even if the status quo is in desperate need of being redesigned. The last people to admit it, even to themselves, will be those whose power flows from their position within the status quo.
Tcl was originally conceived as a glue language, that is, a scripting language featuring extensibility via a separate implementation language. For example, Tcl has a package called TLS which adds SSL/TLS capability to the standard socket operations using OpenSSL. With minimal code changes and rapid deployability, your plaintext connection can run over SSL/TLS.
What's especially good about the Tcl approach is that it doesn't reinvent the wheel. The OpenSSL libraries are there already. It's just a matter of providing a framework to access them, and Tcl makes this part easy. Similarly, Tcl is very nice for accessing system facilities, even novel facilities such as might be found in embedded systems, or cell phones, or web browsers for that matter.
In principle, this is no different than JavaScript extensibility. The debate over which is preferable comes down to language design on one hand and interface support on the other. Both are hard to quantify. I find Tcl elegant as a language, JavaScript not. Also, Tcl has a strong support culture which historically has shown excellent consensus when developing new packages. JavaScript extensions seem to be all over the place. Quite possibly that's due to more widespread use, but it results in a more messy ecosystem, which in turn makes broad deployments such as web applications harder to support.
So I think that, if we imagine a Web 3.0 which provides integration over an essentially unbounded variety of mobile devices, the case could be made that Tcl might ultimately win the race over JavaScript. I don't know this. It remains to be seen. But NaCl demonstrates that it's a possibility, at least.
The real problem isn't old computers, it's new software.
It also depends on which software. I'm writing this on a Linux workstation that's 10 years old. It's got a 1.8GHz processor, 512MB of memory. At work, however, I have to use a Windows laptop that's a year old. Processor is 3GHz quad core, memory is 2GB. I find that, on average, I'm twice as productive on the Linux system than on the Windows system. For some tasks, it's more like ten times more productive.
Some of the difference is certainly attributable to bloat and implementation choices. A cold boot in Windows is much slower than in Linux, for example. But I find that most of the difference in productivity, in steady state, is due to differences in design. The design aspect of either platform hasn't significantly changed over the past decade. Linux is still modular, still highly configurable. It's easy for me to set up applications optimally and automate common tasks. Windows is still monolithic, not meaningfully configurable, and impossible to automate. Therefore it's a much less productive environment for professional work. I'm sure it does fine as a consumer system, but that's not what I need.
The point I'm illustrating here is that, in the total equation, hardware performance is a minor issue. Choice of software is what dominates the equation. I'm glad I made the right choice. It's saved me a lot of money in useless hardware upgrades.
It's a hard subject to write about. The article contains some interesting ideas, along with a fair amount of coarse hyperbole which, unfortunately, serves to make it less credible. And nobody who writes professionally should have trouble using words like "effect" and "proscribe" correctly.
The thing is, readers take writing competence as a proxy for competence generally. It's not an unreasonable strategy. Any reader who's not already a subject matter expert is going to have to accept the writer's expertise on faith, at least provisionally, until he has argued his main points. There's no quicker way to undermine that faith than with poor writing, and that's really unfortunate, because there are some good ideas here.
In fact, the issue is not with the SSL/TLS protocol but with the essentially hierarchical characteristics and application of X.509 certificates, and of course with the operation of the human institutions known as Certificate Authorities. It's true that the setup is a bit fishy. We've allowed a situation to develop where foxes have been hired to guard the henhouse, and because of the hierarchical nature of X.509 we're left with no means of correction except to fire all the foxes and start over from scratch. This alone makes a reasonable case for configuring security controls at a finer level of granularity than at the root CAs. But if the argument is going to go anywhere, we need to see some kind of concrete proposal, not just a dismal assessment of the status quo.
If you're intent on securing your message for confidentiality, encrypt it. To secure for integrity, sign it.
This capability has been around since S/MIME (RFC 2630 in 1999.) It applies to content only, so headers are still exposed, and of course there is still no guarantee of delivery, but pretty much every email user today can sign and encrypt their messages if they want to. Standards for header authentication (for example RFC 4408) have not been as widely adopted.
In short, email is an old protocol - one of the earliest, in fact - and it has several shortcomings. But it's not correct to say that "email is inherently insecure."
The bill has a loaded agenda, there's no doubt about that from the examples it cites. But there are many other examples, such as the ones you've listed. This is a science class, right? It can't be a science class if it doesn't apply the methodology of science. But that leaves a pretty wide field. Anything relevant to science education is a legitimate topic.
I'd argue that this sort of political manipulation would backfire in a big way. Studies of political interference, prejudice and bigotry would all make highly relevant topics.
What we should have done was created a GUI which has exact formal one-for-one-correspondence with the underlying CLI
Yes! Someone gets it.
The characteristic advantage of any CLI is that it's a language. We often refer to languages in terms of their clarity and expressive power, much of which comes from composability. For this reason alone, some CLIs end up being much better languages than others. We need to be aware of this because some people will debate the relative advantages of GUIs and CLIs in terms of some particularly nasty instance of a CLI.
Properly, the debate is between language (stream of symbols interpreted explicitly through syntax) and non-language (stream of events interpreted tacitly and differently by each application). It's then quite clear which has the advantage.
Is it possible to build an application which formally couples the GUI and CLI layers? Well, Richard Stallman did it with emacs. And John Osterhout did it with Tcl/Tk. To be clear, these two examples illustrate different aspects of what it means to couple the layers. Because emacs comes preconfigured as a text editor, the binding between GUI and language elements is already made. We can immediately see how it works and begin to extend it. In the case of Tcl/Tk we begin with nothing more than the language interpreter. If we want a GUI, we have to build one. Then it's on us to ensure that a structured relationship exists between the resulting GUI and our functional elements.
On the other hand, Tcl/Tk has native facilities for unit testing. As you develop a GUI application, you also define a test framework that lets you automatically replay the entire suite of identified use cases without having to involve some unhappy and fallible test user to repetitively point and click. It's not that Tcl/Tk is special in any linguistic sense, it's just that this feature is provided natively, and therefore it's ubiquitous.
Not only do languages provide composability and repeatability, they are easy to document. Don't you hate having to document how to use a GUI application to accomplish a particular task? I sure do. First click on this, then select this, then fill in this, then ensure that this checkbox is in some state or other. Gah. It's an agony to write, there is no formal notation to aid the process, it can't be automatically replayed to verify that what you've written is in fact correct, and whether or not you load it full of attractive screen shots, almost none of your intended audience is going to read it anyway.
Documenting a CLI application is much more representative of actually using the application. You can write precisely what is to be done. Formal notations for the documentation metalanguage are widely understood, and in any case can be described in a couple of paragraphs. And, if your particular use of the application is dauntingly complex to describe in this way, you write a script for it, and document how to run that script instead. Try doing that with a GUI.