making the holy grail of direct manipulation of persistent data structures a realistic proposition. IIRC, this *was* done in multics. Large pointers into small blocks of storage seems wasteful somehow.
"Religion is the last refuge of the scoundrel", or something like that. In any event it is to a scoundrel's advantage if he can claim some sort of religious justification. The people that tortured and killed heretics called themselves "Christians". What else would they call themselves?
You standardize the things that are not worth being different. As a ridiculous example, a sentence is composed of words. Pick each word from the language that best characterizes the exact shade of your meaning. Each word is the best choice, but the sentence is a mess. With a name like Penguin Airlines, there are some natural image effects with the Linux mascot. As long as it's not a horrible choice for the particular job, methinks they'll do just fine.
IIRC, FORTRAN II had COMPLEX as a native type. Probably goes back to the original Formula Translator. Variables I through N defaulted to INTEGER. Other variables defaulted to REAL. DOUBLE PRECISION and COMPLEX had to be specified explicitly. Some kind of hack for Holerith strings. Outside of Holerith strings, spacing strictly for the benefit of human readers, although I think some compilers didn't like END stretched across continuation cards.
If you have lots of formulas and very little logic, FORTRAN is probably the optimal language.
My group, being responsible for privacy at our company, are constantly worried about making inaccurate statements - apparently, we don't need to worry that much Don't count on being able to get away with the same things that Microsoft gets away with. Size works against you. More people have more access to more information about more people. Something of an n-squared or n-cubed problem. Also most industries expect a better sense of ethics from their suppliers, customers, competitors, employers, and employees.
The main problem with centralized authentication is when the authentication for a high-security place is the same as for a low-security place. Use in low security contexts puts the high-security stuff at risk. I could use my/. password as root password on a bunch of servers and be reasonably safe as long as noone can connect the dots, but compartmentalization is much easier and safer. With centralization, any crack anywhere exposes the whole mess. With compartmentalization, any crack exposes only that part.
An example. You have a cashier who takes in money and hands out tickets. You have a ticket-taker who take the tickets when customers enter. You're fairly safe from being ripped off as long as the two don't know each other.
If any of the places that use the authentication can be compromized and obtain too much information, the rewards are greater and the chance of discovery are smaller. Bad odds for the victims.
If your going to be against somthing, at least figure out what it is before standing on the soap box and shouting your opinions to the world. I've never eaten a vulture-burger. I don't have any specific reasons why I would not eat a vulture-burger, but I am not about to find out why by eating a vulture-burger. Microsoft has passed from being presumed innocent to presumed guilty. It is up to Microsoft to show that they cannot misuse the information stored in Passport. That they aren't currently misusing it is not good enough. That's why Sun's Liberty Alliance is outside of Sun. Far too many opportunities for conflict of interest if it's inside.
They are a commercial company with responsibilities mainly to the shareholders. That's like Enron and Worldcom. They kept the price up as long as they could.
Should I learn FORTRAN? Should I use FORTRAN? Different questions, and not as related as one might think. From long ago, an observation that it is better to learn Pascal and use FORTRAN. Learning FORTRAN and using Pascal doesn't work. FORTRAN (I'm thinking FORTRAN-IV (1966 standard, I think)) is in some sense an optimal substitute for raw machine language. It can be very machine/architecture independent. There are things expressible in the language which would be better if they were illegal, but that would break the language. With Fortran77 they had an opportunity to make it a programming language. Instead they left it Fortran. I'd be surprised if Fortran90 were any different. If I had to use Fortan, I'd tend to stick to the basics and not victimize myself into thinking the language would take care of me. If the validity of your results is important, and you are willing to pay the price, Ada should be a good choice. There's stuff in Ada that turns "semantic" errors into "syntactic" errors. This is to avoid cases where a program can give correct results on one architecture and wrong results on a different architecture.
Curiously, the ones you can trust seem to take some effort to ensure that you don't need to trust them. When someone with his hand in my pocket says "Trust me" I start to get more than a little nervous.
You can argue that pure math is applied logic. And of course logic is a sub-subsection of math. Axioms as "self-evident" doesn't work. Finding the right axioms is empirical. You need the right axioms so you don't come up with wrong results. Some forms of the Axiom of Choice seem intuitively obvious, but no one has yet come up with* a well ordering of the reals. (order so that every subset has a least element). *I haven't kept track, but I'm sure I would have heard of that if it happened.
It states who is responsible for maintaining the confidentiality of your password and account information. Not Microsoft. It should mean something else. But that's not what it says.
You (not Microsoft or other corporate entities) are responsible for maintaining the confidentiality of your password and account information. That means that you are responsible for however Microsoft, etc uses or abuses the account. No thanks.
It's a self-propagating, vicious cycle, it gets deeper and deeper, but it does it gradually so that people do not take notice, do not feel cheated to the point of doing something about it. Until something breaks and the powers that be decide that this is "something up with which we will not put". The things that need to be fixed are in the effective collusion between market analysts, investment bankers, and corporate auditors. (Ok "collusions among" for the grammar nazis;) I caught a bit of CSPAN "grilling" a brokerage executive about the "chinese wall" between market analysts and investment banking. Kinda got the impression (from the questions, no information content in the answers) that the "chinese wall" has more holes than Microsoft Windows.;)
There is something of a trickle-down effect. The big losers from the big stock market crash of late '20s were the poor during the depression of the '30s. They didn't have the money to lose in the crash but still suffered. Methinks the ranting and raving is a "Self-Defeating Prophecy". He's right, but only if he and his ilk keep quiet. Good points. Both, together not separately. I think we've reached the point where corporate greed and lack of responsibility is maybe not such a good thing.
I don't know what you're talking about but I 'spect you're right. I do know that attempting to implement a FSA with conventional "structured programming" constructs yields a worse mess than spaghetti. I know just enough LISP to have a healthy respect for what it can express.
Yep. The idea (not Diijkstra's) is that by getting rid of GOTOs programs are magically more manageable. The thing is that a mess of GOTOs can easily lead to an incredibly complex program that does not warrant that degree of complexity, hence the diatribe. The natural way to implement a Finite State Automaton is with GOTOs (and long cryptic labels;). It's been a long time since I've even thought about them, but Diijkstra's guarded commands are insidiously powerful. I'm a bit surprised that essentially nothing has been done with them. He once commented that using them, he was using recursion much less. I'm guessing, but I think the power comes from specifying the partial order inherent in the problem rather than inventing a linear order that the program must follow. With a smart-alecky interpreter it might be possible to make a somewhat effective substitute for a nondeterministic finite state automaton.
Therefore the issue of backdoors in an app need never arise - just deny it permission to open a socket. Right. Close one hole and ignore any communications with apps that DO have permission to open a socket. Security is a perimeter-type thingee. There is no "just" about it.
Microsoft has spent the last 5 years playing catch up to Linux in security and stability. They are still at least 2-5 years behind in both of these areas and I don't see this changing anytime soon. And Linux is maybe 2-5 years behind the *BSDs. OpenBSD: "One remote hole in the default install, in nearly 6 years!" (And that fish looks mad;) Methinks that is actually a stronger statement than when they were running "No remote holes...".
You are assuming.NET will live up to Microsofts hype No matter how good a job Microsoft does, it's a monoculture and there's always a crack somewhere. Linux does not have that problem because there's a bunch of subtly different ones out there and there's always a few wiseacres who insist on doing things their way. Security through obscurity can work, but it does presuppose obscurity. A monoculture is *not* obscure.
Linux has about another two years to continue poking fun at Windows security defects, then Dotnet will be in place and the party will be well and truly over. Yes, but which party? These is something of a progression of Melissa to Code Red and Nimda to Klez. The worms and viruses are getting smarter and Microsoft still doesn't have a clue as to security.
IIS runs as IUSER_ NOT as the System account, and it has done this for years. The default install of SQL Server 2000 runs as a normal Domain user account NOT LocalSystem. But Code Red and friends still propagate. Seems like Microsoft's idea of security has some problems.
Slashdot Mirror
making the holy grail of direct manipulation of persistent data structures a realistic proposition.
IIRC, this *was* done in multics.
Large pointers into small blocks of storage seems wasteful somehow.
"Religion is the last refuge of the scoundrel", or something like that. In any event it is to a scoundrel's advantage if he can claim some sort of religious justification. The people that tortured and killed heretics called themselves "Christians". What else would they call themselves?
You standardize the things that are not worth being different.
As a ridiculous example, a sentence is composed of words. Pick each word from the language that best characterizes the exact shade of your meaning. Each word is the best choice, but the sentence is a mess.
With a name like Penguin Airlines, there are some natural image effects with the Linux mascot. As long as it's not a horrible choice for the particular job, methinks they'll do just fine.
IIRC, FORTRAN II had COMPLEX as a native type. Probably goes back to the original Formula Translator.
Variables I through N defaulted to INTEGER.
Other variables defaulted to REAL.
DOUBLE PRECISION and COMPLEX had to be specified explicitly.
Some kind of hack for Holerith strings.
Outside of Holerith strings, spacing strictly for the benefit of human readers, although I think some compilers didn't like END stretched across continuation cards.
If you have lots of formulas and very little logic, FORTRAN is probably the optimal language.
My group, being responsible for privacy at our company, are constantly worried about making inaccurate statements - apparently, we don't need to worry that much
Don't count on being able to get away with the same things that Microsoft gets away with.
Size works against you. More people have more access to more information about more people. Something of an n-squared or n-cubed problem.
Also most industries expect a better sense of ethics from their suppliers, customers, competitors, employers, and employees.
Does this mean the end of PWS (Personal Web Server)?
The main problem with centralized authentication is when the authentication for a high-security place is the same as for a low-security place. Use in low security contexts puts the high-security stuff at risk. I could use my /. password as root password on a bunch of servers and be reasonably safe as long as noone can connect the dots, but compartmentalization is much easier and safer. With centralization, any crack anywhere exposes the whole mess. With compartmentalization, any crack exposes only that part.
An example. You have a cashier who takes in money and hands out tickets. You have a ticket-taker who take the tickets when customers enter. You're fairly safe from being ripped off as long as the two don't know each other.
If any of the places that use the authentication can be compromized and obtain too much information, the rewards are greater and the chance of discovery are smaller. Bad odds for the victims.
If your going to be against somthing, at least figure out what it is before standing on the soap box and shouting your opinions to the world.
I've never eaten a vulture-burger. I don't have any specific reasons why I would not eat a vulture-burger, but I am not about to find out why by eating a vulture-burger.
Microsoft has passed from being presumed innocent to presumed guilty. It is up to Microsoft to show that they cannot misuse the information stored in Passport. That they aren't currently misusing it is not good enough. That's why Sun's Liberty Alliance is outside of Sun. Far too many opportunities for conflict of interest if it's inside.
They are a commercial company with responsibilities mainly to the shareholders.
That's like Enron and Worldcom. They kept the price up as long as they could.
Should I learn FORTRAN?
Should I use FORTRAN?
Different questions, and not as related as one might think.
From long ago, an observation that it is better to learn Pascal and use FORTRAN. Learning FORTRAN and using Pascal doesn't work.
FORTRAN (I'm thinking FORTRAN-IV (1966 standard, I think)) is in some sense an optimal substitute for raw machine language. It can be very machine/architecture independent. There are things expressible in the language which would be better if they were illegal, but that would break the language. With Fortran77 they had an opportunity to make it a programming language. Instead they left it Fortran. I'd be surprised if Fortran90 were any different. If I had to use Fortan, I'd tend to stick to the basics and not victimize myself into thinking the language would take care of me.
If the validity of your results is important, and you are willing to pay the price, Ada should be a good choice. There's stuff in Ada that turns "semantic" errors into "syntactic" errors. This is to avoid cases where a program can give correct results on one architecture and wrong results on a different architecture.
Curiously, the ones you can trust seem to take some effort to ensure that you don't need to trust them.
When someone with his hand in my pocket says "Trust me" I start to get more than a little nervous.
You can argue that pure math is applied logic. And of course logic is a sub-subsection of math. Axioms as "self-evident" doesn't work. Finding the right axioms is empirical. You need the right axioms so you don't come up with wrong results. Some forms of the Axiom of Choice seem intuitively obvious, but no one has yet come up with* a well ordering of the reals. (order so that every subset has a least element).
*I haven't kept track, but I'm sure I would have heard of that if it happened.
"Algol is an improvement over all its successors".
Probably applies to the old Burroughs mainframes too.
The world needs a Windows clone.
Lindows?
Tony,
They should rename Lindows to Lindex. Windex is what is used to clean windows.... thus Lindex
(from the company president)
Hmmm, wonder how many holes through Microsoft Media Player there are into .NET servers ;)
It states who is responsible for maintaining the confidentiality of your password and account information.
Not Microsoft.
It should mean something else. But that's not what it says.
You (not Microsoft or other corporate entities) are responsible for maintaining the confidentiality of your password and account information.
That means that you are responsible for however Microsoft, etc uses or abuses the account. No thanks.
It's a self-propagating, vicious cycle, it gets deeper and deeper, but it does it gradually so that people do not take notice, do not feel cheated to the point of doing something about it. ;)
Until something breaks and the powers that be decide that this is "something up with which we will not put". The things that need to be fixed are in the effective collusion between market analysts, investment bankers, and corporate auditors. (Ok "collusions among" for the grammar nazis;) I caught a bit of CSPAN "grilling" a brokerage executive about the "chinese wall" between market analysts and investment banking. Kinda got the impression (from the questions, no information content in the answers) that the "chinese wall" has more holes than Microsoft Windows.
There is something of a trickle-down effect. The big losers from the big stock market crash of late '20s were the poor during the depression of the '30s. They didn't have the money to lose in the crash but still suffered.
Methinks the ranting and raving is a "Self-Defeating Prophecy". He's right, but only if he and his ilk keep quiet. Good points. Both, together not separately.
I think we've reached the point where corporate greed and lack of responsibility is maybe not such a good thing.
I don't know what you're talking about but I 'spect you're right. I do know that attempting to implement a FSA with conventional "structured programming" constructs yields a worse mess than spaghetti. I know just enough LISP to have a healthy respect for what it can express.
Yep. The idea (not Diijkstra's) is that by getting rid of GOTOs programs are magically more manageable. The thing is that a mess of GOTOs can easily lead to an incredibly complex program that does not warrant that degree of complexity, hence the diatribe. The natural way to implement a Finite State Automaton is with GOTOs (and long cryptic labels;).
It's been a long time since I've even thought about them, but Diijkstra's guarded commands are insidiously powerful. I'm a bit surprised that essentially nothing has been done with them. He once commented that using them, he was using recursion much less. I'm guessing, but I think the power comes from specifying the partial order inherent in the problem rather than inventing a linear order that the program must follow. With a smart-alecky interpreter it might be possible to make a somewhat effective substitute for a nondeterministic finite state automaton.
Therefore the issue of backdoors in an app need never arise - just deny it permission to open a socket.
Right. Close one hole and ignore any communications with apps that DO have permission to open a socket.
Security is a perimeter-type thingee. There is no "just" about it.
Microsoft has spent the last 5 years playing catch up to Linux in security and stability. They are still at least 2-5 years behind in both of these areas and I don't see this changing anytime soon. ...".
.NET will live up to Microsofts hype
And Linux is maybe 2-5 years behind the *BSDs.
OpenBSD: "One remote hole in the default install, in nearly 6 years!" (And that fish looks mad;) Methinks that is actually a stronger statement than when they were running "No remote holes
You are assuming
No matter how good a job Microsoft does, it's a monoculture and there's always a crack somewhere. Linux does not have that problem because there's a bunch of subtly different ones out there and there's always a few wiseacres who insist on doing things their way. Security through obscurity can work, but it does presuppose obscurity. A monoculture is *not* obscure.
Linux has about another two years to continue poking fun at Windows security defects, then Dotnet will be in place and the party will be well and truly over.
Yes, but which party?
These is something of a progression of Melissa to Code Red and Nimda to Klez. The worms and viruses are getting smarter and Microsoft still doesn't have a clue as to security.
IIS runs as IUSER_ NOT as the System account, and it has done this for years. The default install of SQL Server 2000 runs as a normal Domain user account NOT LocalSystem.
But Code Red and friends still propagate. Seems like Microsoft's idea of security has some problems.