Eh, well, not quite. I can see where that interpretation might have come from, but I'd had ~15 years of dealing with the Linux community at that point, so I don't think inexperience can really factor into it;)
What was really going on with that particular patch posting burst and the resulting, er, discussion was to try and draw some more developer attention, since - as you say - I really was operating solo at that point. Various companies had promised resources (ie people), but nothing was actually forthcoming. In the unlikely event that that particular patchset was accepted it would have been moot, but the real purpose was to highlight how much still needed to be done and to get people to publically express interest in getting dom0 into mainline, ideally backed by action/resources.
And while the feedback from the Linux community was strong and somewhat negative, it also put on record what form an acceptable upstreaming path would take.
The outcome was
- the Xen/dom0 ABI needed to be refined, since the original one required some pretty unpleasant kernel changes, and didn't really make much sense
- I needed to come up with a new, much more incremental dom0 upstreaming strategy
For the second, I did this by making sure that each patch supporting dom0 functionality also had at least some other purpose (many to do with pv-hvm), so there wasn't the perception of an endless stream of "not yet useful patches" (which is frowned upon). It ended up being so incremental that the "can boot as dom0" milestone (2.6.37) came as a complete surprise even to people within the Xen community.
And of course, I got a big boost when Konrad from Oracle and Ian and Stefano from Citrix started contributing a significant amount of time to the dom0 effort, taking over responsibility for getting large chunks of functionality into upstreamable form. Their help really tipped it from being a endless slog into an achievable goal.
On the contrary, the Xen and dom0 kernel versions are largely decoupled. There was a kernel/xen ABI extension added in Xen 3.4 which all the upstream (and post-2.6.32 xen.org) dom0 kernels require, but aside from that there's no coupling.
However, Xen and the usermode toolstack *do* need to have matched versions. You can probably get away with a bit of leeway between them, but the ABI is not considered stable.
I have no idea what changes Sun made to Xen to do their Solaris dom0 work, and I don't know if it's supposed to work on stock xen.org Xen - but if it is, it should work so long as the usermode toolstack is also updated.
Consider yourself lucky. Anecdotally, I've been hearing that it's taking longer and longer. One guy I know was working on an H1 for 9 years before he got it (and he had to file a lawsuit at the end to force matters). Oh, I've been in the US for 10 years on a variety of visas, and had the process restart due to job changes a few times. I was just counting the last uninterrupted attempt...
That's because US immigration policy is more rational. You can get into the US if you have a job offer. UK immigration is a mess. Uh, US immigration is an absolute, complete, utter, total mess. It's a disaster.
No, a job offer is not even slightly sufficient to "get into" the US. You might be able to get in for a while on an H1-B visa, but that's hardly residency. For me, getting residency took 4 *years* while being sponsored by an employer and having no particular difficulties.
It's very hard to get in legally if you have a job offer. I've got friends in the UK who managed to get UK residency fairly easily. A points-based system is much saner than the US's "arbitrary collection of rules" system.
However, if you really want to write a quick script, something like Perl or Python is a better choice, unless you really need that portability.
It is actually pretty hard to write a portable script with a shell. Any non-trivial shellscript has many external dependencies on commands, and its hard to use a subset of commands and features which is common across a wide range of machines.
And then you get things like sort behaving in unexpected ways depending on the locale settings...
In general I've found you get best portability from the portable subset of C; perl and python are pretty good, so long as you're careful to only use standard packages.
No one inside Iraq is for war (note I said war not a change of regime), no human being in his right mind will ask you to give him the beating of his life, unless you are a member of fight club that is, and if you do hear Iraqi (in Iraq, not expat) saying "come on bomb us" it is the exasperation and 10 years of sanctions and hardship talking. There is no person inside Iraq (and this is a bold, blinking and underlined inside) who will be jumping up and down asking for the bombs to drop. We are not suicidal you know, not all of us in any case.
That sounds like someone who's got the freedom to speak his mind. Wonder where lives... Hm, Baghdad perhaps?
Face it: Bush has engineered the situation to justify a war.
Unfortunately MySQL crying about GPL violation is weakened by their apparent failure to understand the GPL with respect to linking.
Their license terms say that a client program linked with their LGPL client library which talks to a separate (GPL) MySQL server is effectively linking with GPL code, and therefore your client should also be under the GPL. (see bullet point 2.)
The FSF's interpretation of the GPL has clearly shown that they believe IPC between separate address spaces is not linking under the GPL; this is the only reasonable interpretation, since there's no single file which contains both your client code and GPL code (and "mere aggregation" doesn't count).
Of course, its up to MySQL AB to adopt whatever interpretation of the GPL they like, and if they choose to use their interpretation to sue someone, they are free to do so. But they won't get much support, and probably won't win; in doing so, they may weaken the GPL.
(And no, this has nothing to do with NuSphere; their case is much more obviously GPL violation that everyone can agree with.)
What he says is somewhat OK, but none of it is an argument which relates open source security to closed source security; they are only arguments as to why open source may not be as secure as it might be.
He's right in that its more complex and nuanced than the simple "everyone will review this" model; unfortunately I think he's emphasised the wrong and less important nuances.
There's two reasons why TIS wouldn't get feedback from their code: noone is reading it, or noone found anything bad to say about it. My own impression of TIS code was that it is pretty high quality, and there wasn't anything bad to say about it. I don't know of any serious holes reported in Gauntlet.
People do read source, and the point of open source is that you at least have the option. Most people don't sit down and read slabs of code before installing it, they wait until they have a reason to do so. For security software, one of those reasons is that someone has found a breach.
Sure, open source means the bad guys can pick through it and find a hole, but they can do that with standard reverse engineering tools with binary-only releases too. But as soon as someone sees a break-in involving and open-source program, you can both audit it and *fix* it. And a piece of software which has shown one flaw is sure to get a lot more attention. If there were holes in Gauntlet, TIS would be deluged in email after the first compromise.
There's another nuance going on here which Levi completely ignores. Because a developer knows their code is going to be visible for all to see, they're much more likely to keep their code clean (and if they don't, someone else will). A programmer in a commercial environment writing code which will only ever be released as a binary is more likely to hack something now to hit the ship date, with a solemn promise to fix it in the next release (and hoping nobody will find the flaw before then).
Code is complex, and reviewing it is also hard; security makes it even more difficult because security isn't a functional property (see http://www.counterpane.com/whycrypto.html). In commercial environments, code reviews are often skipped in order to keep to schedule, with the rationale of "well, the tests pass". You simply can't test the security of a system - it has to be designed in, and it has to be there from the start.
In other words, he's right that programs like ssh is large and complex, and may well have subtle flaws. But there's absolutely no reason to think that a similarly sized closed-source program won't have similar problems; my feeling is that it is more likely, because the closed source commercial model precludes the possibility of code-review at several levels (we don't have time, noone else will see the code anyway). The open source model encourages code review by
publishing the code
often not having commercial time pressures to release it
putting the reputations of the developers on the line, and
making it easier to respond to any attacks in a timely and decentralized manner.
This is essentially the main idea in Greg Egan's latest book, Teranesia, though Egan doesn't suggest its the prime force behind evolution.
His idea is that one of the proteins involved in splitting and recombining the DNA strands becomes a quantum computer which can use the many worlds property of quantum mechanics to calculate the optimial form for the new genome, including defences against predators which don't, but could, exist.
It makes a cute plot device but he doesn't propose it as an explanation of how it all started, which seems to be McFadden's thesis.
Passwords are not obscure, they're secret. The distinction is that their secrecy has well-understood properties, and fit into the rest of the system in well-understood ways. The same applies to any other secret key.
Obscurity strives for complexity and the appearance of security without any substantial way to analyze how the system is secure.
The fact that there's no mathematical basis for understanding the intractability of algorithms used in cryptography (or analyzing computing effort in general) is troubling. However, the current state of cryptography is a collection of techniques which are known to work well in practice and are, so far as anyone knows, secure in well understood ways. If you compose a system using components with known properties, you can make an overall system with known properties.
The real problem with using obscurity is that it strives for complexity for its own sake, whereas real security relies on simplicity. To paraphrase Hoare: "there are two ways of designing a system: keep it simple so there are no obvious problems, or keep it complex so the problems are not obvious".
No, they're going to be running "embedded NT", which needs "only" 12-16MB to run.
It's worth noting that Intel has its own thin server products, which are based on [34]86s and VxWorks, which sell for ~$400-600. Since this is non-MS, cheap, and no per-user licenses, MS hates it.
This new thing looks like a truce between Intel and MS, but it's unlikely to work well. Embedded NT will be too expensive, and $1000-2000 for a box is just a PC without a monitor and keyboard - not really in the running compared to better tuned custom embedded solutions running a more appropriate OS - Linux for example.
Escient can't restrict use of the protocol. Its been published in many forms for years, and they can't make a license retroactively apply to it. The only way to do that is make incompatible changes to the protocol (which is not out of the question).
Their real value is that they have lots of information about lots of CDs. Redesigning the protocol is easy, but pointless without the CD info.
Escient's real option, therefore, is to say something like "CD data free to users using a licensed player", but that's impossible to enforce. Their emphasis on players also ignores lots of other uses for the information.
The real question about this license is "why would you agree to it?" It only makes you give things up without giving you anything in return (the exclusivity clause is particularly onerous, and probably not legal). There's no reason to consider agreeing to it.
While you can certainly point to lots of systems which do similar things, the question is whether they do it in the same way.
Some things, like only sending people stuff they're interested in, almost certainly has prior art (QuakeWorld may be early enough). Their backbone stuff looks a lot like IP multicast and a little like IRC. Unreal uses the importance of events to determine network priority in bandwidth limited situations, but it certainly post-dates this patent.
The other stuff about keeping a unified timebase over all clients on multiple servers with different network latencies is *HARD* and if they've got a good solution they deserve a patent.
On the other hand, a closer reading of the claims leads me to believe that they haven't solved the hard problem.
Slashdot Mirror
Eh, well, not quite. I can see where that interpretation might have come from, but I'd had ~15 years of dealing with the Linux community at that point, so I don't think inexperience can really factor into it ;)
What was really going on with that particular patch posting burst and the resulting, er, discussion was to try and draw some more developer attention, since - as you say - I really was operating solo at that point. Various companies had promised resources (ie people), but nothing was actually forthcoming. In the unlikely event that that particular patchset was accepted it would have been moot, but the real purpose was to highlight how much still needed to be done and to get people to publically express interest in getting dom0 into mainline, ideally backed by action/resources.
And while the feedback from the Linux community was strong and somewhat negative, it also put on record what form an acceptable upstreaming path would take.
The outcome was
- the Xen/dom0 ABI needed to be refined, since the original one required some pretty unpleasant kernel changes, and didn't really make much sense
- I needed to come up with a new, much more incremental dom0 upstreaming strategy
For the second, I did this by making sure that each patch supporting dom0 functionality also had at least some other purpose (many to do with pv-hvm), so there wasn't the perception of an endless stream of "not yet useful patches" (which is frowned upon). It ended up being so incremental that the "can boot as dom0" milestone (2.6.37) came as a complete surprise even to people within the Xen community.
And of course, I got a big boost when Konrad from Oracle and Ian and Stefano from Citrix started contributing a significant amount of time to the dom0 effort, taking over responsibility for getting large chunks of functionality into upstreamable form. Their help really tipped it from being a endless slog into an achievable goal.
On the contrary, the Xen and dom0 kernel versions are largely decoupled. There was a kernel/xen ABI extension added in Xen 3.4 which all the upstream (and post-2.6.32 xen.org) dom0 kernels require, but aside from that there's no coupling.
However, Xen and the usermode toolstack *do* need to have matched versions. You can probably get away with a bit of leeway between them, but the ABI is not considered stable.
I have no idea what changes Sun made to Xen to do their Solaris dom0 work, and I don't know if it's supposed to work on stock xen.org Xen - but if it is, it should work so long as the usermode toolstack is also updated.
Zany. Zany always makes them happy.
And then you get things like sort behaving in unexpected ways depending on the locale settings...
In general I've found you get best portability from the portable subset of C; perl and python are pretty good, so long as you're careful to only use standard packages.
Face it: Bush has engineered the situation to justify a war.
Not at all. The resolution of the Vidomi GPL violation was done by using IPC, with the approval of the FSF.
Unfortunately MySQL crying about GPL violation is weakened by their apparent failure to understand the GPL with respect to linking. Their license terms say that a client program linked with their LGPL client library which talks to a separate (GPL) MySQL server is effectively linking with GPL code, and therefore your client should also be under the GPL. (see bullet point 2.) The FSF's interpretation of the GPL has clearly shown that they believe IPC between separate address spaces is not linking under the GPL; this is the only reasonable interpretation, since there's no single file which contains both your client code and GPL code (and "mere aggregation" doesn't count). Of course, its up to MySQL AB to adopt whatever interpretation of the GPL they like, and if they choose to use their interpretation to sue someone, they are free to do so. But they won't get much support, and probably won't win; in doing so, they may weaken the GPL. (And no, this has nothing to do with NuSphere; their case is much more obviously GPL violation that everyone can agree with.)
He's right in that its more complex and nuanced than the simple "everyone will review this" model; unfortunately I think he's emphasised the wrong and less important nuances.
There's two reasons why TIS wouldn't get feedback from their code: noone is reading it, or noone found anything bad to say about it. My own impression of TIS code was that it is pretty high quality, and there wasn't anything bad to say about it. I don't know of any serious holes reported in Gauntlet.
People do read source, and the point of open source is that you at least have the option. Most people don't sit down and read slabs of code before installing it, they wait until they have a reason to do so. For security software, one of those reasons is that someone has found a breach.
Sure, open source means the bad guys can pick through it and find a hole, but they can do that with standard reverse engineering tools with binary-only releases too. But as soon as someone sees a break-in involving and open-source program, you can both audit it and *fix* it. And a piece of software which has shown one flaw is sure to get a lot more attention. If there were holes in Gauntlet, TIS would be deluged in email after the first compromise.
There's another nuance going on here which Levi completely ignores. Because a developer knows their code is going to be visible for all to see, they're much more likely to keep their code clean (and if they don't, someone else will). A programmer in a commercial environment writing code which will only ever be released as a binary is more likely to hack something now to hit the ship date, with a solemn promise to fix it in the next release (and hoping nobody will find the flaw before then).
Code is complex, and reviewing it is also hard; security makes it even more difficult because security isn't a functional property (see http://www.counterpane.com/whycrypto.html). In commercial environments, code reviews are often skipped in order to keep to schedule, with the rationale of "well, the tests pass". You simply can't test the security of a system - it has to be designed in, and it has to be there from the start.
In other words, he's right that programs like ssh is large and complex, and may well have subtle flaws. But there's absolutely no reason to think that a similarly sized closed-source program won't have similar problems; my feeling is that it is more likely, because the closed source commercial model precludes the possibility of code-review at several levels (we don't have time, noone else will see the code anyway). The open source model encourages code review by
His idea is that one of the proteins involved in splitting and recombining the DNA strands becomes a quantum computer which can use the many worlds property of quantum mechanics to calculate the optimial form for the new genome, including defences against predators which don't, but could, exist.
It makes a cute plot device but he doesn't propose it as an explanation of how it all started, which seems to be McFadden's thesis.
Obscurity strives for complexity and the appearance of security without any substantial way to analyze how the system is secure.
The fact that there's no mathematical basis for understanding the intractability of algorithms used in cryptography (or analyzing computing effort in general) is troubling. However, the current state of cryptography is a collection of techniques which are known to work well in practice and are, so far as anyone knows, secure in well understood ways. If you compose a system using components with known properties, you can make an overall system with known properties.
The real problem with using obscurity is that it strives for complexity for its own sake, whereas real security relies on simplicity. To paraphrase Hoare: "there are two ways of designing a system: keep it simple so there are no obvious problems, or keep it complex so the problems are not obvious".
Well, I didn't know it wasn't supposed to work, so I tried it out. It worked fine! A little slow, but pretty good.
No, they're going to be running "embedded NT", which needs "only" 12-16MB to run.
It's worth noting that Intel has its own thin server products, which are based on [34]86s and VxWorks, which sell for ~$400-600. Since this is non-MS, cheap, and no per-user licenses, MS hates it.
This new thing looks like a truce between Intel and MS, but it's unlikely to work well. Embedded NT will be too expensive, and $1000-2000 for a box is just a PC without a monitor and keyboard - not really in the running compared to better tuned custom embedded solutions running a more appropriate OS - Linux for example.
Escient can't restrict use of the protocol. Its been published in many forms for years, and they can't make a license retroactively apply to it. The only way to do that is make incompatible changes to the protocol (which is not out of the question).
Their real value is that they have lots of information about lots of CDs. Redesigning the protocol is easy, but pointless without the CD info.
Escient's real option, therefore, is to say something like "CD data free to users using a licensed player", but that's impossible to enforce. Their emphasis on players also ignores lots of other uses for the information.
The real question about this license is "why would you agree to it?" It only makes you give things up without giving you anything in return (the exclusivity clause is particularly onerous, and probably not legal). There's no reason to consider agreeing to it.
Where's the full text again?
J
While you can certainly point to lots of systems which do similar things, the question is whether they do it in the same way.
Some things, like only sending people stuff they're interested in, almost certainly has prior art (QuakeWorld may be early enough). Their backbone stuff looks a lot like IP multicast and a little like IRC. Unreal uses the importance of events to determine network priority in bandwidth limited situations, but it certainly post-dates this patent.
The other stuff about keeping a unified timebase over all clients on multiple servers with different network latencies is *HARD* and if they've got a good solution they deserve a patent.
On the other hand, a closer reading of the claims leads me to believe that they haven't solved the hard problem.
J