Not that long ago, competent security was a criminal offense to export. It still is, unless the code is Open Source (and we all know how Microsoft loves Open Source). The practical difference between a Caesar cipher and DES is that the Caesar cipher is faster so more transactions can be performed. You could do more leaving things in plain-text, but regulations usually require encryption of some sort for this kind of data. However, those same regulations don't usually stipulate any particular strength of encryption, so Caesar becomes ideal. The high throughput will sell better and the absence of security means it evades export controls. You end up with the largest possible market.
If there was a recognized, official (or even semi-official) standard API and ABI for cryptography libraries, ITAR would be less of an issue. You could swap out any crypto library in any product and swap in an alternative. You could then use any crypto library (and therefore any crypto algorithm) you liked.
If standards better-mandated what level of security was required, weak algorithms would never be used. No corporation would dare risk the penalties and so no vendor would dare supply soft crypto.
The market's preference for high throughput is perfectly reasonable, but it is often unwilling to invest in security - which is why there are so many issues of this kind. If corporations were more willing to invest in securing their systems, say by using hardware crypto engines to get the high throughput they needed, they would be able to use essentially bullet-proof algorithms without harming the amount of data they could manage.
Doubly so given all the various articles posted here on flaws in SSL safety - starting, many years ago, with someone obtaining Microsoft's root certificates by, well, asking for them. The use of NULLs to produce fake certificates that seem valid, the breakage of MD5-secured SSL certificates -- there has been no shortage of problems for the approach.
The idea of webs of trust is that you can't go out and physically verify the path but you CAN ask others if they're confident that X really is X. In the event that you are on a system where there is a well-defined gateway that can establish a secure tunnel to a well-defined gateway adjacent to the end-point, you have two other points that you can verify. If you can be confident of getting to the gateway AND you are confident that the tunnel really is secure AND you are confident that the far end of the tunnel is who it is supposed to be, I really can't see you getting any safer than that.
The question, though, is how to be sure that the certificates are genuine and are issued to the person or organization they're supposed to be issued to and haven't been forwarded on to anyone else. The first part would seem to require that certificates use hashing schemes still regarded as "safe" AND to require that any tampering (before or after) using NULLs or anything else would foul up the fingerprint. You must be capable of being 100% certain that what you see is what the computer sees is ALL of what the certificate requester submitted as the public information.
The second part would seem to require that weak levels of trust be eliminated from the system. Digital certificates should inspire trust because they deserve it, not because 99% of people are either complacent sheep or suicidal lemmings. To do this, though, the trust must work both ways. The issuer of the certificate has to be just as trustworthy. That's doable. Tough, but doable. One option, borrowing from the idea of witnesses from legal frameworks, is that there must be a neutral third party that can countersign the signature as being between who the parties say they are.
This suggests you want two webs of trust. One, of total strangers who can countersign as witnesses, and one of "friends" who can actively vouch for one or both parties (the more traditional web of trust). But countersigning the key only tells you the key is valid, it doesn't tell you the private half of the key exists only where it claims it does.
Requiring that three points produce valid countersigned certificates would boost the confidence of that, as it requires two independent private keys be compromised. That is less likely than one private key being compromised. Certainly possible, but less likely. If the network ran IPv6 and the IETF doesn't remove any more of the security built into the protocol (and maybe adds a bit of it back), the odds of a stolen key passing inspection would be considerably reduced.
The only thing I can suggest beyond that is that client-side authentication be imposed. Yes, it reduces anonymity, but you cannot both be sure the end-point is who they are supposed to be AND be sure the end-point is 100% anonymous. That doesn't work. Passwords and/or other user authentication verifies the user, but you also want to be sure that the machine the user is talking to is also the machine the server is talking to. Easiest way to do that is have the machine counter-sign the user's authentication data and then have the server query the client machine's certificate to ensure that the certificate matches the counter-signature. There are probably superior methods, but it's better to have a starting point than never start at all.
As for the SSL protocol itself, it uses public-key cryptography. Far as I know, this is perfectly respectable. I'm not keen on the use of HMAC - T-TMAC is considered the most secure, from what I understand, although it's only really good for short messages. Which is fine, since you want the most security on the authentication section. If T-TMAC is used onl
Which makes everything an involuntary subscription service. Similar to the BBC license fee, except that you don't have to pay the license fee if you don't have a television. You don't get to not pay for the website if you don't surf the Internet. Yes, you are correct, it does work. Well, to an extent. The "Dot Com" era was an attempt to go much further towards the logical implications of the system, and the theory of Boom/Bust cycles implies that there are catastrophic instabilities in the current implementation.
I am not going to say that the system is "wrong", but I am going to say that it is incomplete. (Cue theme for "A Beautiful Mind".) Most natural systems are in a state of dynamic equilibrium because there are strong negative feedback loops. The existing model of economics assumes such feedback loops exist, but from these accidental collapses in the stock market, the overheating of the housing market, the lack of change in driving habits when gas prices skyrocketed, etc, we can safely say that Lemming Syndrome is quite capable of causing these feedback loops to never actually happen, if indeed the negative feedback loops exist at all. It therefore seems a logical starting point to determine if, indeed, the a-priori assumptions are valid or if the system (as-is) works because of a statistical consequence of typical conditions. It also makes sense to introduce further, stronger, negative feedback loops to prevent things going catastrophic.
Instead of having unrestricted trades followed by a drop-dead-you-bstard rule, why not have a sliding rule such that the delay is a function of the number of trades pushed through in the previous N ms, where N can be tuned in the future. This would be analogous to packet-dropping schemes in computer networks, in that service is degraded in a controlled manner so as to prevent it ever reaching the point of needing to cut out or die. It also means that inherent instabilities created by the extremely low latencies would be smoothed out, as you'd have a negative feedback loop. Instabilities have a nasty tendency to create all kinds of catastrophic scenarios and you'll never be able to catch them all. By adding a smoothing function, you wouldn't have to.
In other words, the SEC seems to be 50-100 years behind everyone else (although, apparently, only about a decade behind oceanographers, who hadn't realized that interference patterns and feedback loops are as much a part of ocean waves as they are a part of any other dynamic system, and 20 years behind packet network engineers). This is a Solved Problem. We know how to solve these sorts of problems, we know how to solve them without flimsy cut-outs, we know how to solve them dynamically, and we know how to solve them efficiently.
There will be another crash, after these new rules are in place, and it will be traced to this cut-out not cutting in fast enough or the instabilities breaking out of the restricted sandbox. In 60-70 years time, they may well have a smooth function for trade throttling to prevent explosive instabilities from ever forming in the first place rather than trying to catch the explosion as it happens. In that amount of time, a lot of people will be considerably richer from exploiting the flaw and a lot of people will be considerably poorer from the flaw being exploited. Oh well. It's not like this is rocket science.
Re:Got my CD in the mail a few days ago
on
OpenBSD 4.7 Released
·
· Score: 2, Interesting
I'm not sure that it has decreasing relevance. For something like a firewall or other networked appliance (where you don't actually have users logging on and interactively using it), OpenBSD is way ahead of the game. Auditing the kernel and securing that is actually a good strategy for such devices, whereas mandatory access controls would be more of a cycle-hog. For reasons I don't entirely understand - or agree with - the world is slowly moving away from desktops and towards appliance-based computing. Look at the rate Droid is accumulating apps, compared to the rate new stuff is being written for Linux.
I do not know what the ideal security strategy is - I feel that it must involve components that are transparent to any part of the kernel the user or superuser can substantially interact with, because although you can prove a Security Kernel correct mathematically (it is one of the few OS components simple enough), this is useless if there is any means of either accessing the functions protected or re-implementing them, yet nobody likes re-designing implementations and call points are bound to be missed if code changes are required. This means that the security kernel has to act in a manner akin to dynamic probes and inject itself into modules without needing static insertion points. Security then just becomes a form of debug in step mode (continue until next probe, then pause the kernel thread) in which the debug data is analyzed automatically rather than by an engineer.
Services, news services included, stink because the customer is NOT the individual consumer but another corporation. Corporations are not human, they have no intelligence, they aren't even alive in any meaningful sense. If companies could ditch the actual end consumer entirely, they would. End consumers want something - however minimal, drab or insignificant - they can point to. Corporations can't point and (without intelligence) wouldn't know what to point to if they could. It follows that end users are much more expensive to support than corporations. In a market economy, why support the least-profitable sector (which they really don't, as anyone who has tried talking to customer service would know) or even sell to them?
In fact, the Dot Com era was an early attempt to eliminate the need to even have a product -to- sell to end consumers. This is a natural state for this kind of system to drift to. End consumers are always going to be more expensive more expensive than intermediate users.
I don't know if there even IS a solution to this problem, short of an imposed minimal quality of service (which is then guaranteed to be the ONLY quality of service you will ever see) or providing QoS-driven incentives (which will mean we won't have a market economy).
But it cannot be treated as such when the density gets too low. You couldn't treat the edge of the atmosphere as a fluid. I don't care what it is when I use a CFD, only what it behaves like.
The most general solvers are the most handicapped. Even the ridiculously costly commercial solvers (Ansys, Fluent, etc.) solve a limited number of problems. I was working on a project that attempted to numerically simulate the effect of electromagnetic waves on the brain. Obviously, you need to solve the Maxwell's equations in horrible medium that is your brain. That's when I realized how woefully indadequate the commercial solvers (that claim to simulate the problem) are.
My brain's a medium? I thought I heard some dead people in there.:)
Seriously, I entirely agree. I don't for a moment pretend that I'm anything like up enough on PDEs or high-end maths problems (it's been a while) to identify the best packages either. The best I can do is say such software exists. I'll list here the packages I list and use - not just for PDEs but for maths and logic problems as a whole. I'll leave it to you and others skilled in the subject to pass judgement on their quality.
ATLAS - A nice, optimized BLAS (Basic Linear Algebra System) implementation
I'm not sure of any direct uses (flying cars won't be one), but it has implications in other areas of mathematics.
One of the big problems for computational fluid dynamics is that the equations evolved are a real pain. So much so that most of the engineers who need CFD often don't trust the results as better than a first approximation. The new solutions found to the Boltzman equations doesn't really help directly, as CFD uses customized versions of the Navier-Stokes equations for specific types of conditions, but the tools developed to find those new solutions may be useful in producing more generic CFD solutions and may result in analytics techniques that produce far more valid results than current CFD methods.
(A gas can often be treated as a compressible fluid in CFD, so if you can model a gas better, or even just sanity-check intermediate calculations, you can improve CFD for those types of calculations.)
The actual article (as opposed to the blog posting) mentions that the system is 7-dimensional. In maths, this has a different meaning than in physics. It doesn't mean 7 spacial dimensions, it means that in order to define anything you have to have 7 parameters. So, no, boiling water and turning it into a gas won't open a portal to a parallel universe. (If it were that easy, you think I'd still be here?)
For those interested in actually doing the maths, rather than talking about it, there are a great many open source PDE solvers. I've listed a few on Freshmeat, but you could spend the rest of your life collecting them. Might make for a unique hobby, but applying them to this sort of problem seems much more interesting.
The Supreme Court also ruled that children cannot be incarcerated for life without any means of demonstrating being fit for society, with the door left open that any harsh sentence for children must be subject to such review. There was no firm stipulation on the nature of that review or when it took place, only that there had to be one. Presumably, the same ruling would apply to anyone else, provided they could demonstrate reasonable grounds for such a change happening.
Personally, I still assert that sentences should be divided into a punative component and a theraputive component, where the nature of the crime and the nature of the criminal were taken into account on the manner of the dividing. Punative components should never be extensible, that makes no logical sense at all, but I could see a rationale for a theraputive component being extensible on condition that it could never be extended beyond the point that the person met the criteria for reforming, that said criteria could be realistically met and that the criteria made theraputic sense.
This would eliminate the need for a "guilty by reason of insanity" (or indeed "innocent by reason of insanity"), the distinction between criminal insanity and any other kind of insanity or mental illness, the issue of whether a person has paid their dues in the punative sense, indefinite incarceration, and a host of other problematic legal definitions.
Microsoft are patent trolls, so it's likely they either thought they'd already got a patent on the idea or that nobody else took patents seriously either.
I agree that reiserfs has issues, having lost a few filesystems that way. Filesystem integrity is not something calculated from how long the system is marked production or even how stable some find it. We need better tools to stress filesystems so we can quantifiably measure safety for specific types of work. (I expect different results for different conditions, since some find reiserfs works for them.) Just as well Slashdotters are so good at causing stress...
I'm fairly sure you can tunnel SATA over IP. Not sure where you'd get an IP-to-SATA adapter, though, or how much such a device would cost. But it would give him fully networked storage (ANY box on the network would see all drives as though locally connected) without having to use a network filesystem and potentially be as extensible as an IPv4 private network range. But it's heavily dependent on price as to whether it's worth it.
If Slashdot supported the Z font, I'd post the complete schema. Besides, there is only ever one informative post on a Slashdot article and it's never the first one.
I doubt Apple will do bankrupt. If the Lisa and Newton didn't kill them, I seriously doubt the loss of a phone prototype will. From Apple's standpoint, they gained some wonderful free publicity. Sure, it wasn't the greatest of timing, but there really is no such thing as bad publicity. Microsoft promoted Windows CE long before they released a working product. In Britain, Sir Clive Sinclair advertised (and sold) products that were designed and built from the money made from the sales. Never hurt either of them.
It probably wasn't good for Apple, in the sense that you tend to sell more of something you have than something you haven't (except in the US housing market, apparently). However, if they're competent - and I believe they are - they can turn this to their advantage and gain mindshare and therefore sales.
The student did a real no-no. That part should be obvious to anyone. However, I don't think punishing him will help Apple or alter his behaviour. I do think that community service and a requirement to attend counciling might well be appropriate though. If the punishment should fit the crime, then giving to others fits perfectly with taking from others.
The journalist is a much tougher case. Genuine investigative journalism is an absolute must for society, and that WILL involve acts that walk a very thin line between public service and public menace. It is also not remotely unusual for it to involve information or artifacts that the journalist has no legal right to. The Watercase scandal is the "standard" classic example, but there are many others. WikiLeaks, for example, is packed with information that is of dubious legality, but it is also essential that the service exists.
How, then, do you differentiate between journalists who act in a manner that is not in the best interests of those they are investigating when those they are investigating are doing something wrong, versus when those they are investigating are doing something legit? The act itself doesn't change, the rights of the individuals don't change, the only difference is in the extremely indirect link to the end result of the investigation.
In common law, this difference is codified through reasonableness. If a reasonable person would conclude that an investigation in warranted, and the investigation conducted is one a reasonable person would do in such circumstances, then the act becomes reasonable and therefore legitimate. It's the legal version of an exception handler.
However, common law has been downgraded over time, and the reasonableness exception has all but vanished from those judicial systems in which it ever existed at all. Mostly because it's not possible to standardize, it's very subjective, it's potentially open to abuse (and it has been abused, particularly by past UK Governments) and it doesn't fit in well with the modern idea of comparing like with like and having a fully standardized system. It's archaic and arbitrary, in the modern world view.
Unfortunately, private investigation by journalists (or by any unlicensed investigator) relies on a great many archaic, informal notions. The only way you can have someone watching the watchman is if there is minimal or no constraint on watching except on the watchman. (The only constraint on merely watching that seems fair is one that impedes the watchman on being a watchman.) It is ALSO the only way in which such investigation can be evaluated by the legal system (or anyone else) without all investigation being automatically illegal.
This leads to the even-more unfortunate conclusion - the only solution you can have in a wholly modernized legal system is to EITHER allow unreasonable investigations so that the reasonable ones can take place, OR ban the reasonable investigations to prevent the unreasonable ones. There simply aren't any other options if you insist on the kind of system that the US now has and advocates.
I'm not saying the US system is good, bad or indifferent. What I am saying is that ethics has no place in law. Doing somet
I've run filesystems that were considered ok-but-early-adopter on servers before. Early XFS releases, for example. It's perhaps not really comparable as SGI had already developed XFS v1 on their workstations and so most of the code was fairly heavily-tested before the Linux port of XFS v2. But there's another consideration - if you look at the way btrfs is described, most of the individual components look a lot simpler than are used in other next-gen filesystems. The difference isn't great between, say, a b-tree and a b+tree or a b*tree, and most filesystem coders are well beyond the stage of making errors on simple abstract data types (right?), but simple components assembled in complex ways are generally more trust-worthy than complex components assembled in simple ways.
In fact, going back to the early XFS days (when SGI released Red Hat installers and even a few releases before), I found XFS to be much more stable and much more reliable than reiserfs, even though reiserfs has been around longer and was considered mainstream.
Slashdot Mirror
Not that long ago, competent security was a criminal offense to export. It still is, unless the code is Open Source (and we all know how Microsoft loves Open Source). The practical difference between a Caesar cipher and DES is that the Caesar cipher is faster so more transactions can be performed. You could do more leaving things in plain-text, but regulations usually require encryption of some sort for this kind of data. However, those same regulations don't usually stipulate any particular strength of encryption, so Caesar becomes ideal. The high throughput will sell better and the absence of security means it evades export controls. You end up with the largest possible market.
If there was a recognized, official (or even semi-official) standard API and ABI for cryptography libraries, ITAR would be less of an issue. You could swap out any crypto library in any product and swap in an alternative. You could then use any crypto library (and therefore any crypto algorithm) you liked.
If standards better-mandated what level of security was required, weak algorithms would never be used. No corporation would dare risk the penalties and so no vendor would dare supply soft crypto.
The market's preference for high throughput is perfectly reasonable, but it is often unwilling to invest in security - which is why there are so many issues of this kind. If corporations were more willing to invest in securing their systems, say by using hardware crypto engines to get the high throughput they needed, they would be able to use essentially bullet-proof algorithms without harming the amount of data they could manage.
I think the GP means the cards are all probably maxed out, blocked/revoked, or both.
"Infamy! Infamy! They've all got it in fa me!" (Carry On's version)
Doubly so given all the various articles posted here on flaws in SSL safety - starting, many years ago, with someone obtaining Microsoft's root certificates by, well, asking for them. The use of NULLs to produce fake certificates that seem valid, the breakage of MD5-secured SSL certificates -- there has been no shortage of problems for the approach.
The idea of webs of trust is that you can't go out and physically verify the path but you CAN ask others if they're confident that X really is X. In the event that you are on a system where there is a well-defined gateway that can establish a secure tunnel to a well-defined gateway adjacent to the end-point, you have two other points that you can verify. If you can be confident of getting to the gateway AND you are confident that the tunnel really is secure AND you are confident that the far end of the tunnel is who it is supposed to be, I really can't see you getting any safer than that.
The question, though, is how to be sure that the certificates are genuine and are issued to the person or organization they're supposed to be issued to and haven't been forwarded on to anyone else. The first part would seem to require that certificates use hashing schemes still regarded as "safe" AND to require that any tampering (before or after) using NULLs or anything else would foul up the fingerprint. You must be capable of being 100% certain that what you see is what the computer sees is ALL of what the certificate requester submitted as the public information.
The second part would seem to require that weak levels of trust be eliminated from the system. Digital certificates should inspire trust because they deserve it, not because 99% of people are either complacent sheep or suicidal lemmings. To do this, though, the trust must work both ways. The issuer of the certificate has to be just as trustworthy. That's doable. Tough, but doable. One option, borrowing from the idea of witnesses from legal frameworks, is that there must be a neutral third party that can countersign the signature as being between who the parties say they are.
This suggests you want two webs of trust. One, of total strangers who can countersign as witnesses, and one of "friends" who can actively vouch for one or both parties (the more traditional web of trust). But countersigning the key only tells you the key is valid, it doesn't tell you the private half of the key exists only where it claims it does.
Requiring that three points produce valid countersigned certificates would boost the confidence of that, as it requires two independent private keys be compromised. That is less likely than one private key being compromised. Certainly possible, but less likely. If the network ran IPv6 and the IETF doesn't remove any more of the security built into the protocol (and maybe adds a bit of it back), the odds of a stolen key passing inspection would be considerably reduced.
The only thing I can suggest beyond that is that client-side authentication be imposed. Yes, it reduces anonymity, but you cannot both be sure the end-point is who they are supposed to be AND be sure the end-point is 100% anonymous. That doesn't work. Passwords and/or other user authentication verifies the user, but you also want to be sure that the machine the user is talking to is also the machine the server is talking to. Easiest way to do that is have the machine counter-sign the user's authentication data and then have the server query the client machine's certificate to ensure that the certificate matches the counter-signature. There are probably superior methods, but it's better to have a starting point than never start at all.
As for the SSL protocol itself, it uses public-key cryptography. Far as I know, this is perfectly respectable. I'm not keen on the use of HMAC - T-TMAC is considered the most secure, from what I understand, although it's only really good for short messages. Which is fine, since you want the most security on the authentication section. If T-TMAC is used onl
Which makes everything an involuntary subscription service. Similar to the BBC license fee, except that you don't have to pay the license fee if you don't have a television. You don't get to not pay for the website if you don't surf the Internet. Yes, you are correct, it does work. Well, to an extent. The "Dot Com" era was an attempt to go much further towards the logical implications of the system, and the theory of Boom/Bust cycles implies that there are catastrophic instabilities in the current implementation.
I am not going to say that the system is "wrong", but I am going to say that it is incomplete. (Cue theme for "A Beautiful Mind".) Most natural systems are in a state of dynamic equilibrium because there are strong negative feedback loops. The existing model of economics assumes such feedback loops exist, but from these accidental collapses in the stock market, the overheating of the housing market, the lack of change in driving habits when gas prices skyrocketed, etc, we can safely say that Lemming Syndrome is quite capable of causing these feedback loops to never actually happen, if indeed the negative feedback loops exist at all. It therefore seems a logical starting point to determine if, indeed, the a-priori assumptions are valid or if the system (as-is) works because of a statistical consequence of typical conditions. It also makes sense to introduce further, stronger, negative feedback loops to prevent things going catastrophic.
Instead of having unrestricted trades followed by a drop-dead-you-bstard rule, why not have a sliding rule such that the delay is a function of the number of trades pushed through in the previous N ms, where N can be tuned in the future. This would be analogous to packet-dropping schemes in computer networks, in that service is degraded in a controlled manner so as to prevent it ever reaching the point of needing to cut out or die. It also means that inherent instabilities created by the extremely low latencies would be smoothed out, as you'd have a negative feedback loop. Instabilities have a nasty tendency to create all kinds of catastrophic scenarios and you'll never be able to catch them all. By adding a smoothing function, you wouldn't have to.
In other words, the SEC seems to be 50-100 years behind everyone else (although, apparently, only about a decade behind oceanographers, who hadn't realized that interference patterns and feedback loops are as much a part of ocean waves as they are a part of any other dynamic system, and 20 years behind packet network engineers). This is a Solved Problem. We know how to solve these sorts of problems, we know how to solve them without flimsy cut-outs, we know how to solve them dynamically, and we know how to solve them efficiently.
There will be another crash, after these new rules are in place, and it will be traced to this cut-out not cutting in fast enough or the instabilities breaking out of the restricted sandbox. In 60-70 years time, they may well have a smooth function for trade throttling to prevent explosive instabilities from ever forming in the first place rather than trying to catch the explosion as it happens. In that amount of time, a lot of people will be considerably richer from exploiting the flaw and a lot of people will be considerably poorer from the flaw being exploited. Oh well. It's not like this is rocket science.
I'm not sure that it has decreasing relevance. For something like a firewall or other networked appliance (where you don't actually have users logging on and interactively using it), OpenBSD is way ahead of the game. Auditing the kernel and securing that is actually a good strategy for such devices, whereas mandatory access controls would be more of a cycle-hog. For reasons I don't entirely understand - or agree with - the world is slowly moving away from desktops and towards appliance-based computing. Look at the rate Droid is accumulating apps, compared to the rate new stuff is being written for Linux.
I do not know what the ideal security strategy is - I feel that it must involve components that are transparent to any part of the kernel the user or superuser can substantially interact with, because although you can prove a Security Kernel correct mathematically (it is one of the few OS components simple enough), this is useless if there is any means of either accessing the functions protected or re-implementing them, yet nobody likes re-designing implementations and call points are bound to be missed if code changes are required. This means that the security kernel has to act in a manner akin to dynamic probes and inject itself into modules without needing static insertion points. Security then just becomes a form of debug in step mode (continue until next probe, then pause the kernel thread) in which the debug data is analyzed automatically rather than by an engineer.
Services, news services included, stink because the customer is NOT the individual consumer but another corporation. Corporations are not human, they have no intelligence, they aren't even alive in any meaningful sense. If companies could ditch the actual end consumer entirely, they would. End consumers want something - however minimal, drab or insignificant - they can point to. Corporations can't point and (without intelligence) wouldn't know what to point to if they could. It follows that end users are much more expensive to support than corporations. In a market economy, why support the least-profitable sector (which they really don't, as anyone who has tried talking to customer service would know) or even sell to them?
In fact, the Dot Com era was an early attempt to eliminate the need to even have a product -to- sell to end consumers. This is a natural state for this kind of system to drift to. End consumers are always going to be more expensive more expensive than intermediate users.
I don't know if there even IS a solution to this problem, short of an imposed minimal quality of service (which is then guaranteed to be the ONLY quality of service you will ever see) or providing QoS-driven incentives (which will mean we won't have a market economy).
But it cannot be treated as such when the density gets too low. You couldn't treat the edge of the atmosphere as a fluid. I don't care what it is when I use a CFD, only what it behaves like.
My brain's a medium? I thought I heard some dead people in there. :)
Seriously, I entirely agree. I don't for a moment pretend that I'm anything like up enough on PDEs or high-end maths problems (it's been a while) to identify the best packages either. The best I can do is say such software exists. I'll list here the packages I list and use - not just for PDEs but for maths and logic problems as a whole. I'll leave it to you and others skilled in the subject to pass judgement on their quality.
I'd have preferred a solution to Block Transfer Computation and the Skasis Paradigm.
Given that hard maths can take months to work through, three months is actually quite impressive.
I'm not sure of any direct uses (flying cars won't be one), but it has implications in other areas of mathematics.
One of the big problems for computational fluid dynamics is that the equations evolved are a real pain. So much so that most of the engineers who need CFD often don't trust the results as better than a first approximation. The new solutions found to the Boltzman equations doesn't really help directly, as CFD uses customized versions of the Navier-Stokes equations for specific types of conditions, but the tools developed to find those new solutions may be useful in producing more generic CFD solutions and may result in analytics techniques that produce far more valid results than current CFD methods.
(A gas can often be treated as a compressible fluid in CFD, so if you can model a gas better, or even just sanity-check intermediate calculations, you can improve CFD for those types of calculations.)
The actual article (as opposed to the blog posting) mentions that the system is 7-dimensional. In maths, this has a different meaning than in physics. It doesn't mean 7 spacial dimensions, it means that in order to define anything you have to have 7 parameters. So, no, boiling water and turning it into a gas won't open a portal to a parallel universe. (If it were that easy, you think I'd still be here?)
For those interested in actually doing the maths, rather than talking about it, there are a great many open source PDE solvers. I've listed a few on Freshmeat, but you could spend the rest of your life collecting them. Might make for a unique hobby, but applying them to this sort of problem seems much more interesting.
Yes, but do they meet the criteria for criminal insanity or only the criteria for psychological insanity?
The Supreme Court also ruled that children cannot be incarcerated for life without any means of demonstrating being fit for society, with the door left open that any harsh sentence for children must be subject to such review. There was no firm stipulation on the nature of that review or when it took place, only that there had to be one. Presumably, the same ruling would apply to anyone else, provided they could demonstrate reasonable grounds for such a change happening.
Personally, I still assert that sentences should be divided into a punative component and a theraputive component, where the nature of the crime and the nature of the criminal were taken into account on the manner of the dividing. Punative components should never be extensible, that makes no logical sense at all, but I could see a rationale for a theraputive component being extensible on condition that it could never be extended beyond the point that the person met the criteria for reforming, that said criteria could be realistically met and that the criteria made theraputic sense.
This would eliminate the need for a "guilty by reason of insanity" (or indeed "innocent by reason of insanity"), the distinction between criminal insanity and any other kind of insanity or mental illness, the issue of whether a person has paid their dues in the punative sense, indefinite incarceration, and a host of other problematic legal definitions.
No, we only imprison the insane for four years, eight if they're re-elected.
And here I was thinking that it was the Alice you're supposed to ask when she's ten feet tall.
...to e-mail Alice and Bob, rather than advertise that their love-letters are being snooped on?
Microsoft are patent trolls, so it's likely they either thought they'd already got a patent on the idea or that nobody else took patents seriously either.
Well, I found your post interesting, so even if we split the difference, there'd be half a post.
I agree that reiserfs has issues, having lost a few filesystems that way. Filesystem integrity is not something calculated from how long the system is marked production or even how stable some find it. We need better tools to stress filesystems so we can quantifiably measure safety for specific types of work. (I expect different results for different conditions, since some find reiserfs works for them.) Just as well Slashdotters are so good at causing stress...
Yeah, but who wants to live forever?
I'm fairly sure you can tunnel SATA over IP. Not sure where you'd get an IP-to-SATA adapter, though, or how much such a device would cost. But it would give him fully networked storage (ANY box on the network would see all drives as though locally connected) without having to use a network filesystem and potentially be as extensible as an IPv4 private network range. But it's heavily dependent on price as to whether it's worth it.
If Slashdot supported the Z font, I'd post the complete schema. Besides, there is only ever one informative post on a Slashdot article and it's never the first one.
I doubt Apple will do bankrupt. If the Lisa and Newton didn't kill them, I seriously doubt the loss of a phone prototype will. From Apple's standpoint, they gained some wonderful free publicity. Sure, it wasn't the greatest of timing, but there really is no such thing as bad publicity. Microsoft promoted Windows CE long before they released a working product. In Britain, Sir Clive Sinclair advertised (and sold) products that were designed and built from the money made from the sales. Never hurt either of them.
It probably wasn't good for Apple, in the sense that you tend to sell more of something you have than something you haven't (except in the US housing market, apparently). However, if they're competent - and I believe they are - they can turn this to their advantage and gain mindshare and therefore sales.
The student did a real no-no. That part should be obvious to anyone. However, I don't think punishing him will help Apple or alter his behaviour. I do think that community service and a requirement to attend counciling might well be appropriate though. If the punishment should fit the crime, then giving to others fits perfectly with taking from others.
The journalist is a much tougher case. Genuine investigative journalism is an absolute must for society, and that WILL involve acts that walk a very thin line between public service and public menace. It is also not remotely unusual for it to involve information or artifacts that the journalist has no legal right to. The Watercase scandal is the "standard" classic example, but there are many others. WikiLeaks, for example, is packed with information that is of dubious legality, but it is also essential that the service exists.
How, then, do you differentiate between journalists who act in a manner that is not in the best interests of those they are investigating when those they are investigating are doing something wrong, versus when those they are investigating are doing something legit? The act itself doesn't change, the rights of the individuals don't change, the only difference is in the extremely indirect link to the end result of the investigation.
In common law, this difference is codified through reasonableness. If a reasonable person would conclude that an investigation in warranted, and the investigation conducted is one a reasonable person would do in such circumstances, then the act becomes reasonable and therefore legitimate. It's the legal version of an exception handler.
However, common law has been downgraded over time, and the reasonableness exception has all but vanished from those judicial systems in which it ever existed at all. Mostly because it's not possible to standardize, it's very subjective, it's potentially open to abuse (and it has been abused, particularly by past UK Governments) and it doesn't fit in well with the modern idea of comparing like with like and having a fully standardized system. It's archaic and arbitrary, in the modern world view.
Unfortunately, private investigation by journalists (or by any unlicensed investigator) relies on a great many archaic, informal notions. The only way you can have someone watching the watchman is if there is minimal or no constraint on watching except on the watchman. (The only constraint on merely watching that seems fair is one that impedes the watchman on being a watchman.) It is ALSO the only way in which such investigation can be evaluated by the legal system (or anyone else) without all investigation being automatically illegal.
This leads to the even-more unfortunate conclusion - the only solution you can have in a wholly modernized legal system is to EITHER allow unreasonable investigations so that the reasonable ones can take place, OR ban the reasonable investigations to prevent the unreasonable ones. There simply aren't any other options if you insist on the kind of system that the US now has and advocates.
I'm not saying the US system is good, bad or indifferent. What I am saying is that ethics has no place in law. Doing somet
I've run filesystems that were considered ok-but-early-adopter on servers before. Early XFS releases, for example. It's perhaps not really comparable as SGI had already developed XFS v1 on their workstations and so most of the code was fairly heavily-tested before the Linux port of XFS v2. But there's another consideration - if you look at the way btrfs is described, most of the individual components look a lot simpler than are used in other next-gen filesystems. The difference isn't great between, say, a b-tree and a b+tree or a b*tree, and most filesystem coders are well beyond the stage of making errors on simple abstract data types (right?), but simple components assembled in complex ways are generally more trust-worthy than complex components assembled in simple ways.
In fact, going back to the early XFS days (when SGI released Red Hat installers and even a few releases before), I found XFS to be much more stable and much more reliable than reiserfs, even though reiserfs has been around longer and was considered mainstream.