The only good thing about it is all the flash ads that I don't have to see or even download since I don't run flash.
With a name like "Flash", there's no way I'm gonna download and run it.
I have a cavalier attitude towards security. I am writing this from NT Workstation that hasn't been patched for 2 or 3 years. I am logged on as root (domain administrator!). I never log off when I leave. A few of the computers have the logon name and password (both the same) writ bold on the keyboard. I don't keep up with Microsoft worms very much anymore. My users click on things they shouldn't rarely enough that I find it hilarious that they fell for a sucker play. I will occasionally make comments that they're getting sneakier.
That said, I will not download something with a name like "Flash". Far too risky.
Nah, the solution is for the mail client to be in enough of a sandbox/jail/whatever that the only thing the mail client is capable of messing up is the mail client itself. I should be able to click on all sorts of malware with the assurance that regardless of how well it is constructed, it cannot affect anything outside its scope. Since there will be attachments I want to open or run or save somewhere, I need the ability to reach into the mail client from the outside and pick up or put down whatever I please. Basically, the mail client can be pick on by everybody else and cannot pick on anyone. Microsoft has it backwards.
Which is a nice way to kill the non-OEM auto industry.
Which then kills the OEM auto industry.
Think about it. The reason people drive cars instead of using public transportation is that people want to drive their cars.
Take away the hot rods, drag races, NASCAR, restored classics, and the ability to do something to somehow customize your set of wheels, and you and a lot of other people will realize that there are better ways to use their excess money.
In most functional programming languages you can code (for instance) state machine transitions directly by 'calling' the next state. Since the call is in tail position, it acts almost exactly like GOTO.
Hmmmmm, that's enough to give an unfair advantage over raw assembler on assembler's own turf.
Just out of interest, have you ever tried to solve any problems that were not inherently recursive (e.g. traversing a tree) using a functional language?
OK, I'll take a nibble on that one.
In a former life, with an End-of-Lifed FORTRAN compiler and some ASM structural code, I have actually done functional programming that was compiled by FORTRAN. One stunt was to replace an undecipherable FORTRAN program with a brute-forced, top-down, implementation of the definition of what the program was supposed to accomplish. Despite spending almost all its time figuring out what to do next, it was actually a hair faster that the mess it replaced.
Some observations:
If a problem is inherently recursive, the optimum solution is not recursive! You want recursion so you don't run into major problems handling minor stuff. Essentially, recursion allows RETURN to go back to from whence it came, regardless of how it got there and regardless of what else is going on. In non-recursive FORTRAN, recursive CALLs work. Once a recursive CALL is made however, there is at least one RETURN that doesn't.
A trace of the Program Counter doing functional stuff is incredibly uninformative. That is with knowledge of all levels of all parts.
The advantage of functional programming is not with the parts of the system that have been thoroughly analyzed and you know the best way to do it. The advantage is that you state what you need and slop some stuff underneath that's good enough to work in that context. At some point the top-down functional programming has to meet the bottom-up fundamentals. The bottom-up stuff needs to be well-defined, as in the results of all theoretically possible inputs against all theoretically possible states. Unless you do it yourself, it is essentially guaranteed that the bottom-up is not defined to your liking. The definition must include the results of putting 1000 bytes in a 100 byte buffer. There is no good definition. There are a lot of very bad definitions.
I have the impression that functional programming will be much more effective if you can read machine language.
We did not, and do not, employ IBM for assisstance with Linux. We do not use a distribution from IBM, nor have we in the past. The only company who has given us Linux "services" is RedHat, and that was a support agreement which did us no good, since they were unable to help us with the migration (they basically told us that what we wanted to do was impossible). The speed and efficiency with which Linux was deployed was a direct result of J.Greers work, followed by the work that myself and a few others did. [Emphasis added]
Completely credible. I would disagree that the RedHat support did you no good. It's more like insurance that you don't use. The migration sounds like something that you can do yourself, but no one else can do it for you. Too many details wherin the devil lies. Methinks the value of the support is if you should chance upon something where the OS is wrong, you're well up in the pecking order to get it fixed. The value of Open Source is that if RedHat is wrong, there are no artificial barriers to demonstrating that fact. There is no silver bullet, but basically it allows you to push forward an extra level at minimal expense.
Google's getting difficult to use because the junk peddlers are learning to hack it. Maybe the next great search engine will be one that is hack resistant.
The next great search engine is most likely Google, as they struggle to stay ahead of the junk peddlers. You have much the same situation with Slashdot, as they struggle to stay ahead of meept and its successors.
For many broadband over the powerlines may be the only way to get connected to the information age. I hope, for these peoples sake, that the broadband via powerlines isn't curtailed and that Ham operators are forced to find ways to not interfere with those services.
Ever try to run ethernet over telephone wires? Over long distances?
Now add a few thousand volts to the brew. Methinks you'd have better luck with tin cans and string.
As long as the paid placements are delineated as such (e.g. Google's paid listings) they may not be such a bad thing.
Methinks they are a good thing, so long as they do not influence the rankings in the main list.
As long as Google can survive and keep their integrity, I'm in no hurry to look for anything better.
Other things being more or less equal, I'll buy from an advertiser in Google.
more upfront and honest In the long haul, that's always better to deal with.
You get all the worms and viruses because your computer is not upfront and honest with you. Think about it. That's why the malware doesn't stick to Linux.
And according to Microsoft's security chief, it there isn't a patch for it, it isn't vulnerable.
Re:Ugh, these aren't viruses...
on
The Virus Squad
·
· Score: 1
Fortunately, end-users also make no distinction between malware (adware and spyware) and virusses {Emphasis added]
The all want to control your computer, and by controlling your computer control you. They are widespread enough that the virus known as "Norton Anti" comes preinstalled on new Dells.
That's why blaming software vendors like Microsoft is stupid. Will four ARE YOU SURE YOU WANT TO RUN THIS warnings before allowing the execution of an attachment do any more than three?
No, I'd put the blame squarely on software vendors like Microsoft. Four ARE YOU SURE YOU WANT TO RUN THIS warnings won't do any good. OneNo amount of emergency IT sessions with the staff explaining precautionary tactics involving attachments is going to change that You must be doing something wrong. I've done one "emergency session" and that was more of a "heads up". A few years back on the first of the random subject thingees. (Thanks to the Slashdot Early Warning System!)
The computer is your friend? With friends like that you don't need any enemies. The computer has a problem? That's the nature of computers. It doesn't mean that you have a problem. The computer wants you to run worms/viruses/trojans. There are things called booby-traps. They are designed to catch boobies. Always blame Microsoft. (Shoot first then ask questions). Effective. Annoyingly effective. Savvy, well trained users? Maybe, but they've been given the bare minimum of trianing, usually less, so if they are, they've done it on their own.
The PHBs and the CXOs get a version that comes with Enterprise support that they pay for, and the Geeks get an open source free version that they can use that has no support.
Good summary, but the ecology is actually a good bit more complicated than that. Big Business: "We're paying top dollar for what the Hackers got for free last year." Hackers: "We're being used as free unpaid debuggers for Big Business software."
True, but so what. Big Business is paying for the privilege of not going through the blood, sweat and tears that the Hackers endured. Big Business is also paying for the displacement of the bugs found and fixed by the hackers. Hackers wind up with cutting-edge software they otherwise couldn't afford.
Encountering, finding and fixing a bug is enormously cheaper when done by Hackers than when done by Big Business. Hackers won't find them all (some bugs can be encountered only at enterprise volumes and levels), but every bug the Hackers keep away from Big Business helps enormously.
Really, I can't see how everyone won't win. Exactly. (Assuming nobody gets greedy;) The wins are not small. You don't really think IBM is backing open source because it's cheap, do you?
Then there will be enough libre programmers to make decent libre IDEs etc, and the proprietary Java will wither away (and Sun with it).
Actually, that is what you do not want.
IBM's customers don't wnat AIX or Linux, they want AIX and Linux. Similarly, we don't want free or proprietary Java, we want free and proprietary Java.
Symbiosis can be described as mutual parasitism. It's not a mutual agreement among equals, it's a very lop-sided agreement among non-equals that happens to be vastly beneficial to all sides. You should see some of the beginnings of this in the Star/Open Office scene. If it can be done without bungling it too badly, both sides gain what would otherwise be an impossible advantage. Note that this has to do with the entire infrastructure, not just the sequence of bits that make up the programs.
Methinks that pushed to their respective limits, Proprietary reads like "I paid good money for this. I am unhappy with it. Make me happy.", while Libre reads like "You have the source. Fix it yourself and send us the patch. If we like it (the patch) we might even put in the next release.". That's when you discover that Theo is really a sweet kindly soul;-) Even if the sequence of bits is identical, the extremes are not only worlds apart but each would suffer immensely if its opposite were to vanish.
ONLY two Javas does sound wierd. (Microsoft's bastardization doesn't count.) For some time there has been JRE downloadable from IBM and from SUN and seems like at least some partials elsewhere.
What you want are multiple implementations with everything sufficiently standardized that except for legitimate proprietary issues, you don't have to care or even be aware of which particular implementation you are using.
Actually, the question -- or the worry -- is more around how to prevent somebody from forking Java and kill the "Write Once, Run Everywhere" idiom.
And methinks this is where IBM is even more on SUN's side than SUN itself. Think what needs to be the replacement for mountains of COBOL on mainframes.
I'm no expert on Java, but every time I look at it I get visions of gaggles of mainframes. (No I don't mean clusters. Clusters are a cheap hack to pretend to a non-existant level of reliability).
I guess it all comes down to what USENIX means by 'stopped support'.
Exactly. And the precise meaning is definable by whoever's whim of the moment.
Essentially, SCO software is skating on thin ice. If you somehow manage to fall through, passersby are about as likely to throw anchors as life preservers your direction.
Just because someone received it from SCO doesn't mean that they've [I assume you mean the recipient] done anything inappropriate. While... are in their rights to support whomever they'd like, this seems excessively vindictive.
Nothing in the GPL implies that any recipient has any rights to any kind of support. Vindictive? Maybe but hardly excessively so.
This stuff is just making explicit what was pretty obvious from day 1.
Let's say you as a customer are using SCO software and are running into some sort of problem, real or imagined, that might be related in some way to nmap. Who you gonna call? "Sorry, that's not supported" is the short form. Even the very existence of nmap on affected systems can be grounds for very short support calls.
Slashdot Mirror
The only good thing about it is all the flash ads that I don't have to see or even download since I don't run flash.
With a name like "Flash", there's no way I'm gonna download and run it.
I have a cavalier attitude towards security. I am writing this from NT Workstation that hasn't been patched for 2 or 3 years. I am logged on as root (domain administrator!). I never log off when I leave. A few of the computers have the logon name and password (both the same) writ bold on the keyboard. I don't keep up with Microsoft worms very much anymore. My users click on things they shouldn't rarely enough that I find it hilarious that they fell for a sucker play. I will occasionally make comments that they're getting sneakier.
That said, I will not download something with a name like "Flash". Far too risky.
but their [Microsoft's] own technology is making it easier for the other side to obtain shreds of information we probably shouldnt be privy to.
It's called "Trusted Computing".
Nah, the solution is for the mail client to be in enough of a sandbox/jail/whatever that the only thing the mail client is capable of messing up is the mail client itself. I should be able to click on all sorts of malware with the assurance that regardless of how well it is constructed, it cannot affect anything outside its scope. Since there will be attachments I want to open or run or save somewhere, I need the ability to reach into the mail client from the outside and pick up or put down whatever I please. Basically, the mail client can be pick on by everybody else and cannot pick on anyone. Microsoft has it backwards.
Faced with an old can of worms, do you
a) copy the can and try to fix the copy? or
b) take the opportunity to create your own fresh can of worms?
Methinks there may be rather less to be found than SCO expects.
Which is a nice way to kill the non-OEM auto industry.
Which then kills the OEM auto industry.
Think about it. The reason people drive cars instead of using public transportation is that people want to drive their cars.
Take away the hot rods, drag races, NASCAR, restored classics, and the ability to do something to somehow customize your set of wheels, and you and a lot of other people will realize that there are better ways to use their excess money.
makes them [Microsoft] look like they can't compete on their own merits
...
Well, considering that Microsoft's latest ads for Microsoft Office seems to be aimed at people who can't compete on their own merits,
In most functional programming languages you can code (for instance) state machine transitions directly by 'calling' the next state. Since the call is in tail position, it acts almost exactly like GOTO.
Hmmmmm, that's enough to give an unfair advantage over raw assembler on assembler's own turf.
Just out of interest, have you ever tried to solve any problems that were not inherently recursive (e.g. traversing a tree) using a functional language?
OK, I'll take a nibble on that one.
In a former life, with an End-of-Lifed FORTRAN compiler and some ASM structural code, I have actually done functional programming that was compiled by FORTRAN. One stunt was to replace an undecipherable FORTRAN program with a brute-forced, top-down, implementation of the definition of what the program was supposed to accomplish. Despite spending almost all its time figuring out what to do next, it was actually a hair faster that the mess it replaced.
Some observations:
If a problem is inherently recursive, the optimum solution is not recursive! You want recursion so you don't run into major problems handling minor stuff. Essentially, recursion allows RETURN to go back to from whence it came, regardless of how it got there and regardless of what else is going on. In non-recursive FORTRAN, recursive CALLs work. Once a recursive CALL is made however, there is at least one RETURN that doesn't.
A trace of the Program Counter doing functional stuff is incredibly uninformative. That is with knowledge of all levels of all parts.
The advantage of functional programming is not with the parts of the system that have been thoroughly analyzed and you know the best way to do it. The advantage is that you state what you need and slop some stuff underneath that's good enough to work in that context. At some point the top-down functional programming has to meet the bottom-up fundamentals. The bottom-up stuff needs to be well-defined, as in the results of all theoretically possible inputs against all theoretically possible states. Unless you do it yourself, it is essentially guaranteed that the bottom-up is not defined to your liking. The definition must include the results of putting 1000 bytes in a 100 byte buffer. There is no good definition. There are a lot of very bad definitions.
I have the impression that functional programming will be much more effective if you can read machine language.
We did not, and do not, employ IBM for assisstance with Linux. We do not use a distribution from IBM, nor have we in the past. The only company who has given
us Linux "services" is RedHat, and that was a support agreement which did us no good, since they were unable to help us with the migration (they basically told us that what we wanted to do was impossible). The speed and efficiency with which Linux was deployed was a direct result of J.Greers work, followed by the work that myself and a few others did. [Emphasis added]
Completely credible.
I would disagree that the RedHat support did you no good. It's more like insurance that you don't use. The migration sounds like something that you can do yourself, but no one else can do it for you. Too many details wherin the devil lies. Methinks the value of the support is if you should chance upon something where the OS is wrong, you're well up in the pecking order to get it fixed. The value of Open Source is that if RedHat is wrong, there are no artificial barriers to demonstrating that fact. There is no silver bullet, but basically it allows you to push forward an extra level at minimal expense.
Google's getting difficult to use because the junk peddlers are learning to hack it.
Maybe the next great search engine will be one that is hack resistant.
The next great search engine is most likely Google, as they struggle to stay ahead of the junk peddlers.
You have much the same situation with Slashdot, as they struggle to stay ahead of meept and its successors.
For many broadband over the powerlines may be the only way to get connected to the information age. I hope, for these peoples sake, that the broadband via powerlines isn't curtailed and that Ham operators are forced to find ways to not interfere with those services.
Ever try to run ethernet over telephone wires?
Over long distances?
Now add a few thousand volts to the brew.
Methinks you'd have better luck with tin cans and string.
As long as the paid placements are delineated as such (e.g. Google's paid listings) they may not be such a bad thing.
Methinks they are a good thing, so long as they do not influence the rankings in the main list.
As long as Google can survive and keep their integrity, I'm in no hurry to look for anything better.
Other things being more or less equal, I'll buy from an advertiser in Google.
more upfront and honest
In the long haul, that's always better to deal with.
You get all the worms and viruses because your computer is not upfront and honest with you. Think about it. That's why the malware doesn't stick to Linux.
But as a CUSTOMER of EV1, I am pissed that my box is now a "legally licensed SCO product". How can I possibly live this down???
It's worse. If the German logic holds, you now can be sued by SCO because you now have a legally licensed SCO product.
And according to Microsoft's security chief, it there isn't a patch for it, it isn't vulnerable.
Fortunately, end-users also make no distinction between malware (adware and spyware) and virusses {Emphasis added]
The all want to control your computer, and by controlling your computer control you.
They are widespread enough that the virus known as "Norton Anti" comes preinstalled on new Dells.
That's why blaming software vendors like Microsoft is stupid. Will four ARE YOU SURE YOU WANT TO RUN THIS warnings before allowing the execution of an attachment do any more than three?
No, I'd put the blame squarely on software vendors like Microsoft. Four ARE YOU SURE YOU WANT TO RUN THIS warnings won't do any good. OneNo amount of emergency IT sessions with the staff explaining precautionary tactics involving attachments is going to change that
You must be doing something wrong. I've done one "emergency session" and that was more of a "heads up". A few years back on the first of the random subject thingees. (Thanks to the Slashdot Early Warning System!)
The computer is your friend? With friends like that you don't need any enemies.
The computer has a problem? That's the nature of computers. It doesn't mean that you have a problem. The computer wants you to run worms/viruses/trojans. There are things called booby-traps. They are designed to catch boobies.
Always blame Microsoft. (Shoot first then ask questions). Effective. Annoyingly effective.
Savvy, well trained users? Maybe, but they've been given the bare minimum of trianing, usually less, so if they are, they've done it on their own.
What kind of a "pro" would consider that a useful feature?
A Microsoft "pro", obviously.
(Sorry about that;)
The PHBs and the CXOs get a version that comes with Enterprise support that they pay for, and the Geeks get an open source free version that they can use that has no support.
Good summary, but the ecology is actually a good bit more complicated than that.
Big Business: "We're paying top dollar for what the Hackers got for free last year."
Hackers: "We're being used as free unpaid debuggers for Big Business software."
True, but so what.
Big Business is paying for the privilege of not going through the blood, sweat and tears that the Hackers endured. Big Business is also paying for the displacement of the bugs found and fixed by the hackers.
Hackers wind up with cutting-edge software they otherwise couldn't afford.
Encountering, finding and fixing a bug is enormously cheaper when done by Hackers than when done by Big Business. Hackers won't find them all (some bugs can be encountered only at enterprise volumes and levels), but every bug the Hackers keep away from Big Business helps enormously.
Really, I can't see how everyone won't win.
Exactly. (Assuming nobody gets greedy;)
The wins are not small. You don't really think IBM is backing open source because it's cheap, do you?
Then there will be enough libre programmers to make decent libre IDEs etc, and the proprietary Java will wither away (and Sun with it).
;-)
Actually, that is what you do not want.
IBM's customers don't wnat AIX or Linux, they want AIX and Linux.
Similarly, we don't want free or proprietary Java, we want free and proprietary Java.
Symbiosis can be described as mutual parasitism. It's not a mutual agreement among equals, it's a very lop-sided agreement among non-equals that happens to be vastly beneficial to all sides. You should see some of the beginnings of this in the Star/Open Office scene. If it can be done without bungling it too badly, both sides gain what would otherwise be an impossible advantage. Note that this has to do with the entire infrastructure, not just the sequence of bits that make up the programs.
Methinks that pushed to their respective limits, Proprietary reads like "I paid good money for this. I am unhappy with it. Make me happy.", while Libre reads like "You have the source. Fix it yourself and send us the patch. If we like it (the patch) we might even put in the next release.".
That's when you discover that Theo is really a sweet kindly soul
Even if the sequence of bits is identical, the extremes are not only worlds apart but each would suffer immensely if its opposite were to vanish.
What? Two Javas? This sounds weird.
ONLY two Javas does sound wierd. (Microsoft's bastardization doesn't count.)
For some time there has been JRE downloadable from IBM and from SUN and seems like at least some partials elsewhere.
What you want are multiple implementations with everything sufficiently standardized that except for legitimate proprietary issues, you don't have to care or even be aware of which particular implementation you are using.
Actually, the question -- or the worry -- is more around how to prevent somebody from forking Java and kill the "Write Once, Run Everywhere" idiom.
And methinks this is where IBM is even more on SUN's side than SUN itself.
Think what needs to be the replacement for mountains of COBOL on mainframes.
I'm no expert on Java, but every time I look at it I get visions of gaggles of mainframes. (No I don't mean clusters. Clusters are a cheap hack to pretend to a non-existant level of reliability).
I guess it all comes down to what USENIX means by 'stopped support'.
Exactly. And the precise meaning is definable by whoever's whim of the moment.
Essentially, SCO software is skating on thin ice. If you somehow manage to fall through, passersby are about as likely to throw anchors as life preservers your direction.
Just because someone received it from SCO doesn't mean that they've [I assume you mean the recipient] done anything inappropriate. While ... are in their rights to support whomever they'd like, this seems excessively vindictive.
Nothing in the GPL implies that any recipient has any rights to any kind of support. Vindictive? Maybe but hardly excessively so.
This stuff is just making explicit what was pretty obvious from day 1.
Let's say you as a customer are using SCO software and are running into some sort of problem, real or imagined, that might be related in some way to nmap. Who you gonna call?
"Sorry, that's not supported" is the short form. Even the very existence of nmap on affected systems can be grounds for very short support calls.
Then how the hell do we work out which side we're on?
This is Slashdot.
We are on both sides (or against both sides depending on viewpoint;)
You have a significant tactical advantage if you can convince your enemy to "bunch up".