That's very efficient and probably adequately responsible of you. But, if you had the federal government's resources at your disposal, I would hope you would have the competence to achieve adequate coverage using ssl and an array of government-managed mirror sites, which I think is the sort of redundancy originally seen as DARPANET's strength. P2P is more like redundant vulnerability.
Not all government agencies have the same resources as the high profile ones. Many of them run on inadequate budgets and with a severe shortage of qualified staff. For these people, the simplest option may be the best one. I see no reason why a bittorrent transfer of an encrypted file could not achieve adequate security.
I realize that isn't Limewire, but what company public or private wants employees running Limewire or uTorrent on their desktop computers? Is there a major business case for that? If so, I have no idea what it is. It sounds like screwing around to me.
Speaking as the IT director of a private company, we have a machine that runs a bittorrent client in order to download updates for several pieces of software where we have found torrents the fastest and most reliable way of getting updates.
We have also considered using bittorrent with a private tracker as the easiest way of getting large chunks of data to clients.
The number 1 question here is "Why is this computer with classified information connected to the Internet, anyway?". It's VERY easy to "physically modify to prevent running P2P" by simply disconnecting the ethernet cable.
Erm... because the people working with the classified information also need Internet access? And I doubt most of them have the information in question on their physical machine anyway, so disconnecting the ethernet cable would prevent them doing any work.
Slightly tangential, but I never did understand why we primarily evaluated the life supporting capability of a planet based on whether water could be present.
One reason is that liquid water is an amazing solvent, and there are few other simple substances that would be as likely to form a substrate for life to begin (at least in as far as we understand how such a process might occur).
Some things I read seem to suggest that they want to do JIT (or something like it) of this intermediate language (correct me if I'm wrong).
They already have a JIT compiler for their intermediate language, but it isn't the primary development focus. I think it was more of a "it would be cool if..." kind of thing.
The main thrust of development is in link-time optimizations and code analysis.
Actually they want to be able to fork the compiler anytime they feel like. With gcc it's not possible, so some corporations are investing their time in LLVM.
It's slow, It's as fast as any browser I've used. You probably haven't tried using it on any machine older than about 2 years old. Firefox is quite unresponsive, particularly on javascript-intensive sites, compared to many other browsers, including Internet Explorer. Very long pages with lots of links cause it real trouble. Try this page. On my system (2.66GHz Celeron D, 1GB RAM) there's a ~10 seconds pause after the page loads before I can scroll or switch tabs, and ~3 seconds between clicking on one of the links and the new page starting to load. IE6 handles it pefectly.
I also don't think this is related to extensions. I'm not using anything unusual (popup alt attribute, tabbrowser prefs, flashblock, web developer).
and it crashes I use Firefox quite extensively every single day for both business and personal uses and cannot recall it ever crashing. Not once, not ever. I've been using it since Firebird 0.6 and used many supposedly "unstable" nightly builds in earlier days. I trust it enough to use it during business presentations with clients rather than IE on which our applications have been most extensively tested. I've rarely had crashes until 2.0.0.11, but I've had about 3 over the last 3 weeks. I think there's something wrong with this build.
As for Scientific Method, by all means propose a simple objective way to test the two available hypotheses... On which point, have you ever heard of Occam's razor?
Hypothesis 1: the same number of cables get cut in the past two weeks as in the entire 50 years previous to that. Hypothesis 2: An organization hostile to certain groups in the Middle East "accidentally" cut key cables to take those groups offline.
Hmm. Occam's razor. Sure I have a copy of that around here somewhere. Ah, yes, here it is...
entia non sunt multiplicanda praeter necessitatem
Unfortunately, I don't see how this helps your argument. Hypothesis 2 requires an additional non-necessary entity to explain the observation compared to hypothesis 1.
In other words: We should have written the constitution and the law books as the US did in Japan after WWII, with some minor input by the Afghanis, to prevent stuff like this from happening.
From what I understand of the situation, this sentence does exceed the court's constitutional power. But the court isn't interested in hearing constitutional arguments, and there's nobody else to turn to. I don't think anything we could have done with their constitution would have prevented this.
If your programs are running the the same address space, they are the same process in the Unix and VMS/NT sense.
Except that in an environment like Singularity, they are in separate protection domains: the difference is that address spaces aren't the method of protection being used. Or would you consider Singularity a single-tasking multi-threaded OS?
This ought to be tagged as coming from the "Lack of Redundancy Department".
The only strange thing is that if you look at the map, there's plenty of redundancy. All the affected countries had to do is route their traffic east rather than west and everything would have been fine (if, perhaps, a little slow). Why, then, was the failure so catastrophic?
I suppose with singularity, there is some blurring between the kernel and compiler, but given that all the code is running in supervisor mode, it is still definitely the kernel doing the work. If you can figure out how to do IPC without a kernel, publish dammit. My scheme would only work in some circumstances, but I believe that the effort involved in writing processes to create those circumstances is justified by the benefits: IPC for just the cost of a method call.
The circumstances are:
* Both processes are running in the same memory space (e.g. via a mechanism like singularity's) * The type of IPC to be performed is a synchronous RPC. * The recipient method does not require synchronization with any other behaviour in the recipient process * The compiler is able to prove that the recipient method cannot throw an exception, or it is acceptable to the recipient process that any exception thrown be ignored.
In these circumstances, I see no reason at all why the invoking process cannot simply call the method of the recipient process, in its own context and on its own stack. I see no reason, given this, why the kernel would have to be involved at all.
I believe [language-based protection] is the correct design for future systems, and is my answer to the micro vs monolothic question: Neither!
Such systems still need kernels (e.g. Singularity, JX, etc.) though. And most of the current crop of kernels for those systems resemble microkernels more than they do monolithic ones (perhaps because the disadvantages of microkernels mostly disappear once you stop using memory protection).
There's almost nothing a compiler can do about IPC. Since it involves a context switch and some kernel work, it's entirely dependent on the OS and hardware.
Singularity handles IPC without a context switch by delegating security requirements to the compiler rather than relying on the hardware. I'm not sure of the precise details of how MS have done it, but my own thoughts on the matter suggest that it would be possible to implement IPC without involving the kernel at all.
BTW, why the hell would it be the compiler's job to handle IPC? Shouldn't it the job of whatever is behind the OS API?
The compiler doesn't really handle IPC: what happens is that the compiler (or rather the loader) verifies that the programs are type- and memory-safe before allowing them to run. Then they are all loaded into a single memory space so that IPC is trivial. It's a neat concept, although not the first time it has been implemented (see an OS called 'JX').
Depends. Ever hear of FUSE? It's been showing up in quite a few distros for the capabilities it buys by running outside of kernel space. It's become so important, that it has been ported to BSD, Solaris, and Mac OS X.
What does it do? Why, it's a monolithic driver that provides an interface to support userspace filesystem drivers. i.e. A microkernel in practice, if not in definition. Ergo, the grandparent's point about a slow migration.
Unfortunately, the problem with FUSE is that it's painfully slow. And yes, I do know what I'm talking about, having written drivers for it myself.
Slashdot Mirror
That's very efficient and probably adequately responsible of you. But, if you had the federal government's resources at your disposal, I would hope you would have the competence to achieve adequate coverage using ssl and an array of government-managed mirror sites, which I think is the sort of redundancy originally seen as DARPANET's strength. P2P is more like redundant vulnerability.
Not all government agencies have the same resources as the high profile ones. Many of them run on inadequate budgets and with a severe shortage of qualified staff. For these people, the simplest option may be the best one. I see no reason why a bittorrent transfer of an encrypted file could not achieve adequate security.
But a dog's got personality. And personality goes a long way.
So do rats. You don't see people easing up on their vermin poisoning, though, do you?
I realize that isn't Limewire, but what company public or private wants employees running Limewire or uTorrent on their desktop computers? Is there a major business case for that? If so, I have no idea what it is. It sounds like screwing around to me.
Speaking as the IT director of a private company, we have a machine that runs a bittorrent client in order to download updates for several pieces of software where we have found torrents the fastest and most reliable way of getting updates.
We have also considered using bittorrent with a private tracker as the easiest way of getting large chunks of data to clients.
The number 1 question here is "Why is this computer with classified information connected to the Internet, anyway?". It's VERY easy to "physically modify to prevent running P2P" by simply disconnecting the ethernet cable.
Erm... because the people working with the classified information also need Internet access? And I doubt most of them have the information in question on their physical machine anyway, so disconnecting the ethernet cable would prevent them doing any work.
Actually, under the UK's Wilson Convention not even the coppers are allowed to do that, although it hasn't stopped them recently...
AFAICT, the Wilson Convention (or Doctrine) is not legally binding. See, for example, the Times's summary of it here.
Not even on extrasolar planets?
The headline doesn't say extrasolar.
Slightly tangential, but I never did understand why we primarily evaluated the life supporting capability of a planet based on whether water could be present.
One reason is that liquid water is an amazing solvent, and there are few other simple substances that would be as likely to form a substrate for life to begin (at least in as far as we understand how such a process might occur).
Some things I read seem to suggest that they want to do JIT (or something like it) of this intermediate language (correct me if I'm wrong).
They already have a JIT compiler for their intermediate language, but it isn't the primary development focus. I think it was more of a "it would be cool if..." kind of thing.
The main thrust of development is in link-time optimizations and code analysis.
Actually they want to be able to fork the compiler anytime they feel like. With gcc it's not possible, so some corporations are investing their time in LLVM.
Huh? LLVM *is* a gcc fork.
I also don't think this is related to extensions. I'm not using anything unusual (popup alt attribute, tabbrowser prefs, flashblock, web developer). and it crashes I use Firefox quite extensively every single day for both business and personal uses and cannot recall it ever crashing. Not once, not ever. I've been using it since Firebird 0.6 and used many supposedly "unstable" nightly builds in earlier days. I trust it enough to use it during business presentations with clients rather than IE on which our applications have been most extensively tested. I've rarely had crashes until 2.0.0.11, but I've had about 3 over the last 3 weeks. I think there's something wrong with this build.
doesn't it have to be around or under 100nm to be considered nano?
AFAIK, the most common definition is under 1um, so this just qualifies.
I just had this scary vision of a slashdot where moderators were prohibited from ... err ... "leaving negative feedback".
If you're going from sydney to London you could go up the pacific and over the north pole, you wouldnt have to slow down until you got to scotland.
Or, indeed, over the south pole and up the atlantic, which seems to me to avoid land better.
I've seen more computer generated designs for supersonic passenger aircraft than I can count.
Is this going to be a real commercial jet, or just another cock tease?
Looking at the backgrounds of the company's key staff, I'd say this has a real chance of getting off the ground (pun intended).
As for Scientific Method, by all means propose a simple objective way to test the two available hypotheses... On which point, have you ever heard of Occam's razor?
Hypothesis 1: the same number of cables get cut in the past two weeks as in the entire 50 years previous to that.
Hypothesis 2: An organization hostile to certain groups in the Middle East "accidentally" cut key cables to take those groups offline.
Hmm. Occam's razor. Sure I have a copy of that around here somewhere. Ah, yes, here it is...
entia non sunt multiplicanda praeter necessitatem
Unfortunately, I don't see how this helps your argument. Hypothesis 2 requires an additional non-necessary entity to explain the observation compared to hypothesis 1.
In other words: We should have written the constitution and the law books as the US did in Japan after WWII, with some minor input by the Afghanis, to prevent stuff like this from happening.
From what I understand of the situation, this sentence does exceed the court's constitutional power. But the court isn't interested in hearing constitutional arguments, and there's nobody else to turn to. I don't think anything we could have done with their constitution would have prevented this.
If your programs are running the the same address space, they are the same process in the Unix and VMS/NT sense.
Except that in an environment like Singularity, they are in separate protection domains: the difference is that address spaces aren't the method of protection being used. Or would you consider Singularity a single-tasking multi-threaded OS?
This ought to be tagged as coming from the "Lack of Redundancy Department".
The only strange thing is that if you look at the map, there's plenty of redundancy. All the affected countries had to do is route their traffic east rather than west and everything would have been fine (if, perhaps, a little slow). Why, then, was the failure so catastrophic?
print (repr(("test", 2.5)))
Okay, this is just starting to look like LISP now. If I wanted to code LISP, I knew where to find it. How about:
>>> print (("test",2.5))
('test', 2.5)
?
Java introduced Generics, but still returns Object from Generic Collections for backwards compatibility.
Huh? As far as I can see, List.get() (for example) returns E.
The circumstances are:
* Both processes are running in the same memory space (e.g. via a mechanism like singularity's)
* The type of IPC to be performed is a synchronous RPC.
* The recipient method does not require synchronization with any other behaviour in the recipient process
* The compiler is able to prove that the recipient method cannot throw an exception, or it is acceptable to the recipient process that any exception thrown be ignored.
In these circumstances, I see no reason at all why the invoking process cannot simply call the method of the recipient process, in its own context and on its own stack. I see no reason, given this, why the kernel would have to be involved at all.
I believe [language-based protection] is the correct design for future systems, and is my answer to the micro vs monolothic question: Neither!
Such systems still need kernels (e.g. Singularity, JX, etc.) though. And most of the current crop of kernels for those systems resemble microkernels more than they do monolithic ones (perhaps because the disadvantages of microkernels mostly disappear once you stop using memory protection).
There's almost nothing a compiler can do about IPC. Since it involves a context switch and some kernel work, it's entirely dependent on the OS and hardware.
Singularity handles IPC without a context switch by delegating security requirements to the compiler rather than relying on the hardware. I'm not sure of the precise details of how MS have done it, but my own thoughts on the matter suggest that it would be possible to implement IPC without involving the kernel at all.
BTW, why the hell would it be the compiler's job to handle IPC? Shouldn't it the job of whatever is behind the OS API?
The compiler doesn't really handle IPC: what happens is that the compiler (or rather the loader) verifies that the programs are type- and memory-safe before allowing them to run. Then they are all loaded into a single memory space so that IPC is trivial. It's a neat concept, although not the first time it has been implemented (see an OS called 'JX').
Depends. Ever hear of FUSE? It's been showing up in quite a few distros for the capabilities it buys by running outside of kernel space. It's become so important, that it has been ported to BSD, Solaris, and Mac OS X.
What does it do? Why, it's a monolithic driver that provides an interface to support userspace filesystem drivers. i.e. A microkernel in practice, if not in definition. Ergo, the grandparent's point about a slow migration.
Unfortunately, the problem with FUSE is that it's painfully slow. And yes, I do know what I'm talking about, having written drivers for it myself.