Most of the people i know in the "community" despise SPAM.
I'm sure that most of the people you know also think girls are icky.
The Internet is clogged with spam.
Yes, and unlike RedHat's mailing, Spam is indiscriminate. You get it because you have an email address and for no other reason. That's why it's annoying. I've never wanted to sell crap in my spare time, see hot shaved teens (well, not on a computer), and I've heard the Good News(tm) about Jesus(r) more times than I can remember.
I use all spamblock methods I can, and STILL get tons of the crap.
Yeah, me too. And y'know what? When some spam slips through, I hit the DEL key and get on with my life. But I guess a "life" is something I have that you don't. Well, that and pubic hair.
In short, I think it reflects poorly on RedHat.
Fine... and your smug pettiness reflects well on Debian? Unfortunately, smug pettiness seems de rigeur for people with debian.org addresses.
Some people's Linux boxes crash, some people's NT boxes crash....
So what is your point exactly?
My point is that seeing is believing.
I've seen an NT box crash. I've never seen a Linux box crash. I've seen OS/2's GUI lock up (face it, who hasn't?) but I've never seen the machine actually go down. My point? NT sucks.
You claim this property of an OS is a demonstration of lack of scalability. "UNIX == not scalable" if you follow your logical argument.
I strongly doubt you could follow anyone's logical argument, or for that matter, identify a logical argument were it presented to you by a team consiting of Socrates, Descartes and Lt. Data.
You said OS/2 didn't have a security subsystem. It does and it's flexible. That's the argument. OS/2 is more scalable than NT in a variety of ways as is UNIX. In terms of security, they are less flexible architecturally. That may or may not be a problem.
No, the whole OS does. The threading is just slow as dirt.
So if OS/2 was (not the preterite) so good, how come you can't admit NT OS is is the dogs bollocks!?
NT has a crappy GUI compared to OS/2
NT is slower than OS/2
NT is more bloated than OS/2 (perhaps its most notable accomplishment)
NT is less stable than OS/2 (and everytime is gets nearly as stable, they release new brokenware)
NT has at least four Java systems that run on it, none of which run as fast as IBM's for OS/2.
The list goes on...
OS/2 completely lacked a security subsystem, unfortunately.
OS/2 has a security API which allows you to add a security subsystem appropriate for the risk level of the system. If you have a low-risk system, it is not encumbered by a bloated and slow security system. If you have a high-security system, you can install a high-security security manager. This is called scalability, something OS/2 also does better than NT.
Too bad you don't have a clue subsystem in which to install a clue.
Try implementing some applications using some of the extensive multithread APIs in the NT OS
[API's listed]
the core of the OS is amazingly well thoughtout and designed by experienced software engineers.
Yes, and those engineers work at IBM where they developed OS/2. Not only was that threading capability stolen from OS/2, but it was stolen badly. OS/2's threading is much faster and doesn't crash constantly.
...and then come back and feel embarrassed...
I wouldn't think of it! Please, the embarassment is all yours.
When we say we want Linux to "win," what does that mean? I can think of two interpretations:
We want Linux to be a no-comprimise Free Operating System. Because Free Software relies on grass-roots volunteers for development, advocacy may have some effect. It may convince one hobbyist or University department to avoid Linux. That loss may ultimately translate into a loss to the Linux community.
On the other hand, Open Source projects are usually started because of an immediate need. There are millions of Linux users out there and their needs tend to cover quite a bit. I have yet to find something I needed to do that didn't already have an open source project going...
We want Linux to be the Enterprise Computing Platform for the next decade. Here, advocacy has little effect. I meet with CEO's and CIO's for companies ranging from Fortune 50 companies to startup dot-com's. Many excutives have an interest in Linux because of the very same business reasons espoused by Eric Raymond and other "Open Source Capitalists." None of them has yet to say,"Hey, aren't Linux users a bunch of infantile pricks?" They don't care. Heck, half of the excutives are infantile pricks. They just care about the almighty bottom line and Linux pricing looks really good on the ol' spreadsheet.
Fluent in a dead language. When Nietzsche wrote about the Superman, did he have you in mind or what?!
Perl code is always interpreted, just like all programming languages, including Java and C++.... your firmware is doing that interpretation.
What if there's no firmware? You... uh... did know that not all processors have firmware? Right? You're not trying to argue a point outside your narrow and increasingly inconsequential sphere of expertise? You wouldn't do that, would you?
Your pop-culture... references are completely lost on me...
Well, at least they're in good company. My brilliant insights are completely lost on you too.
I do not do television... I pursue a long-forgotten diversion called the reading of books.
You might try it some time.
Fear not, I have not lost the ability to read, although your posts are inspiring me to try. I have also not become so narrowminded and stagnant that I can'n appreciate music, film, television, dance or any number of arts.
Get out more.
-trp P.S. I left you a typo to criticise! I'm try to be kind to the rhetorically handicapped.
Converting source code into bytecode is compiling. Period.
Fine. It's compiling. I wrote several times (enough times for you to read it at least once) that "compiling" doesn't have a very precise definition. Nobody is going to argue with you that what you call compiling is compiling. I'm certainly not.
It matters not what's goingto be handling those bytecodes, be it a code generator or a bytecode interpreter.
Again (for what, the fourth time?), I'm not disagreeing with this. What we were debating was whether Perl is "interpreted" or "compiled." In the likely case that your memory is as defective as the rest of your cognitive aperati, the important point of the original poster was that Perl is interpreted. You haven't really refuted that; all you've done is establish that "compile" and "interpret" are not mutually exclusive. Don't pull a muscle patting yourself on the back.
For the last time: if the bytecode is not loaded into the CPU in an instruction fetch, it's being interpreted. Period. Even you, Lord God Price of Perl, use the words "bytecode interpreter."
You can use the word "compile" any way you want. You're not going to change the fact that Perl is interpreted.
I can think of plenty of words on my own much more easily than I could stick somebody else's words into my prose.
You are sooooooo cool; when's your guest spot of "Friends"?
...the mere current existence of this chip that interprets Java bytecodes means that [javac] really is a... compiler, but that the... lack of an equivalent chip for Perl bytecode interpretation... indicates that the Perl thingie-that-might-be-a-compiler isn't really a compiler at all.
Yes, and I'll go further: even if the picoJava chip didn't exist, the fact that you could create one would be sufficient. I don't think a "picoPerl" chip could be designed, much less fabricated.
That means that all I'll have to do to make the Perl thingie-that-wishes-it-were-a-compiler into a true compiler, is,... wave my magic wand and create a chip that happens to directly use the Perl bytecodes as its native instructions.
Yes, that's what I said. Should I say it again? Would that help?
Meanwhile, get a really good wand, Tom 'cause it will take some powerful magic to implement Perl in silicon. Gosling designed Java to be implementable in an embedded computer. Wall had no such plans with Perl and I don't think it's possible. Of course, you've made it clear to anyone still reading this thread that I'm a numbskull who knows nothing of the true "Computer Sciences", so post your schematic post haste and make me the laughingstock of slashdot.
Because I can already convert the Perl bytecodes into something to feed a C compiler...
...means you can compile Perl to native. Big deal. You don't do this operation at runtime and you don't meet my condition that the bytecodes get loaded into a processor (even a hypothetical one) by an instruction fetch cycle. In this oh-so-cutsie example, the bytecodes never hit the instruction pipeline at all.
If you want to call a Perl-to-native process "compiling," I'll be in agreement. Most of the time, however, Perl is interpreted by a "perl.exe". Again, you seem to be the only person who finds this distinction puzzling.
You have demonstrated... [blah blah blah]
So, when you're losing an argument, you retreat into "my thesaurus can beat up your thesaurus"? Pathetic.
So, [javac] is not really a compiler the way everyone says it is
No, it is a compiler the way everyone says it is, you smug bastard.
Everyone (meaning anyone with enough of a clue to be making these kinds of statements) says that javac compiles Java into bytecode for a Java machine. Pretty much nobody has a machine designed to run Java, so the bytecode is interpreted by JVMs which are compiled to run on real machines. Again, nobody seems to have a problem with this, except you.
And, again, the problem is that "compile" does not have a strict definition. Maybe you could formulate one and develop a new career promoting it. Instead of lecturing, teaching and writing on Perl (a subject of interest to many), you could lecture, teach and write on the proper use of the word "compile", which is a subject of interest to pretty much no one.
Personally, because I use Java so much, I tend to use the term "native" instead of "compiled", because "Java compiler" becomes a confusing term when people are trying to discuss Java-to-native versus Java-to-bytecode compilers.
Now, back to your little pet peeve. There is a chip, the picoJava chip, that runs bytecode native (that's bytecode compiled from Java source). There no picoPerl chip. You cannot run a Perl program unless you either have a Perl interpreter or you compile the Perl source to a native binary.
Again, here's another career opportunity, Tom. You could invent the Perl Virtual Machine and propose a hypothetical picoPerl chip and then, maybe people would start talking about compiling Perl the way they talk about compiling Java.
Until then, you will just have to suffer from compiler envy.
I realize that many Linux user are on a budget; this advice is more for business-type users who have a T1 and some more resources.
The poster is right about ICMP, with regards to the RPF's. Dire warnings aside, a lot of people deny ICMP and work just fine.
A better solution is to program your choke router (that's ther router between your server(s) and the Internet) to block ICMP from passing into your network. The router can answer ICMP queries like MTU size, without exposing your server farm to cracker sniffing with ICMP.
You can also get fancy and deny specific ICMP. For example ICMP echo is not necessary, and ICMP netmask discovery gives out information you may not want to share. Neither of these steps break any legitimate network operations.
I came up with a better definition that avoids this obvious case:
If whatever is considered the executable form of the program (what you'd send to someone and say "run this") is not loaded directly into the processor (whatever the hardware designers of your system would consider "the CPU")
via an instruction fetch cycle, then it is interpreted.
If you are unclear what exactly constitutes a CPU is or what differentiates an instruction fetch cycle from any other kind of cycle, RTF Hardware Docs.
I'm sorry to be a stickler for correctness and honesty here, but someone has to fight against the confusion...
Start with yourself. I know what I mean. Most people know what I mean. I understand what you're getting at, but it's a total waste of time.
The root of the problem is that you can't really have a Science of computers for the same reason you can't have a Science of furniture. For example, everyone knows what a "couch" is, but can you precisely define it? Go ahead and try, but you'll leave some couches out of the definition or, inadvertently, include benches (which are not couches).
Same goes with "interpreted" or "compiled." Suffice to say that compiled code is fed via electrical signals into the processeor (whether that processor is one a chip, or a board). If the processor never performs an actual instruction fetch cycle on whatever is considered the program's "executable form" (such as bytecode for Java), then it's interpreted. I know, "ew, gross, hardware, reagisters, bus cycles! That's... hardware." Yeah, it is and maybe you shouldn't get so high and mighty when entering areas of computer "science" in which you have no expertise, Tom.
Yes, Tom, those of us who have actually designed CPUs know that there may be microcode (or even several levels of microcode) in the processor. That just means the definition isn't perfect, but it's servicable and everybody knows what it means.
Except you.
I can't believe you have time for this flame. Jave digging into your server-side mindshare?
A language is interpreted if it's able to generate dynamic code and run it at run time.
Java can do this (you can generate new classes in bytecode on the fly), BASIC can do this (you can evaluated BASIC code in strings), Lisp can do this and non-compiled Perl can do this.
Compiled C/C++ cannot do this. You can generate machine code on the fly, but you can't generate C/C++ code on the fly and run it at run time. It has to be compiled.
Perl isn't like Java - for the most part, it's a server-side scripting language, not a half-compiled binary which is meant to run on the client.
I'll defer to tchrist's clarifications of the perl side of this statement.
On the Java side, nobody said you had to run Java on a client. In fact, Java's most vital current development is on the server side. Some Perl bigots find this threatening because Java servlets are displacing Perl CGI, but Java and Perl have different strengths and weakness -- they are not interchangable and we should just stop trying to compare them.
Unlike most people, I've actually met Michael Milken. He's a really, really, nice guy. I didn't bring up the subject of his past misdeeds, but I get the impression that he has some remorse for how out of hand things got.
AFAIK, the real crime of Mike Milken was his success in selling junk bonds
Unfortunately, this success was due, in part, with misrepresentation of the risk involved in buying junk bonds. As a result, a lot of due dilligence was corrupted and the American taxpayer had to help clean up the mess. He got what he deserved.
I liked the movie and the audience cheered and clapped quite a bit. I assume this included O.J. Simpson, who was seated a few rows behind me in the theatre.
We waited all day to be the first in line for the 7PM show, and Simpson just waltzes right in using his celebrity powers. I don't know where he got the idea the rules don't apply to him...
I agree with Rob. I haven't used a word processor in a long time under Linux.
Translation: I've never been on a project important enough to need a formal proposal, requirements analysis or a design document.
Keep up the good work. I've made some good money cleaning up spaghetti code written by code-cowboys who couldn't be bothered with sissified fancy-pants hoohah like documentation.
I worked for a couple of years writing OS/2 device drivers and learned, in the process, how vendors decide how to spend their driver development dollars.
First of all, a lot of driver development was funded directly by IBM. The Linux equivalent are the user-written drivers (thanks, Don!) out there now.
But not all the drivers were written by IBM. In fact, you can still find OS/2 drivers on fairly recent products. What motivated vendors to write OS/2 drivers and why won't they write Linux drivers for a similarly-sized market?
The important answer is that hardware companies don't see the market as a collection of end users, but as a collection of buyers: small, medium and large. The large buyers dictate what the products look like.
If 20000 people write and say "Give us Linux," that is considerably less important than one person calling up and saying,"I want 20000 machines with Windows 98 on 19995 of them and Linux on 5 of them." If you look at the cost per sale and the cost of custom configurations, that volume buyer will get her Linux, but the 20000 individuals will get the run-around. In other words, the "Market Size" argument is bullshit; it's a sales volume issue, but more complex than "how many Linux boxen." In this example, a 20000-unit sale hinged on only 5 corporate Linux users, just as it once hinged on a small percentage of corporate OS/2 users.
So, back to the peripheral vendors: Let's say that Dell has just announced they are going to ship Linux (oh wait, they did). Now, they probably did this because a Fortune 500 CIO asked their VP of Sales "what [their] Linux strategy" is. Viola! Now they have one -- not for us, but for a small number of key volume clients.
But Dell doesn't make their own peripherals. They buy video chips, SCSI chips and so forth. So, having decided to support Linux, they go to their vendors and say,"So, what's your Linux strategy?" Now, even if Dell only sells one machine with Linux on it, it has to run. So are they going to buy millions of SCSI chips from the vendor who doesn't have a Linux driver? Of course not. So... do you want to be the one chip vendor who doesn't have a Linux driver? Duh, no.
Once upon a time, OS/2 had that "necessary bullet item" status. Vendors shelled out thousands of dollars to consultants (like me) to write the obligatory OS/2 driver. OS/2 flamed out of the marketplace and nowadays most vendors happily ignore the OS/2 market. Linux is hitting that "hot" phase right about now. Unlike OS/2, Linux doesn't have a parent company to abandon it, so it's unlikely to decrease in popularity.
Bottom line: expect and exponential growth in hardware support, particularly server stuff.
>> Sell it when Linux starts beating NT in corporate use surveys (notice I didn't say "if").
I guess you will have to sell your DELL stock quickly then:
Yes, yes, we've all read that "Dell plans to ship Linux." This isn't the event I mentioned, but let's pretend that your reading comprehension issn't severely impaired and I actually did say "sell when Dell offers Linux."
Dell is broken up into several divisions. They are strongly bound now, but diverging. Dell may be publicly announcing that they are offering Linux, but when, where and how? Will Linux even be mentioned on its online store? That's Dell Online, the second most profitable web site in the world and the highest-availability channel for buying Dell computers.
A lot of companies are offering Linux, but so far it's been to corporate clients through their corporate sales. It's almost impossible to get a consumer machine loaded with Linux, even from people who claim to support it. My point stands; this situation is just a bit more complex than I laid it out.
May company gives us two "floating holidays" to accomodate varying relgions or personal needs. I am now the only official Jedi in my office. Of course, this year's Jedi Holiday is on the 19th...
(When I booked plane travel to L.A. leaving on the 18th and returning on the red-eye on the 20th, the ticket agent guessed "Star Wars?" -- this is gonna be huge).
Well, since a lot of Cyrix's engineering talent bailed out of CONVEX when it was in its death throws years ago, I imagine that they'll know what to do...
...of course that means not blaming the executives and primary stock-holders for being completely oblivious to market and technological trends.
Truth? You are all jealous of Bill and his ideas. He makes money because the VAST MAJORITY like his products.
News Flash: The Vast Majority(tm) didn't decide either way.
"Like" implies favor. Favor implies choice. For most users, choice does not exist.
Perhaps you just emerged from a deep freeze, or your mom just let you on the Internet last week, so I'll fill you in on some news stories covered in depth here and... well, everywhere.
First of all, it's been well documented that you can't buy a PC from a major brand unless it has Windows on it. This includes IBM PC's and IBM makes OS/2, one of Window's supposed rivals. Have you ever heard someone say,"When the sales guy at Gateway asked me which OS I wanted, I chose Windows, because it's the best." No, you haven't and you never will, because no Gateway sales rep is going to ask that question. Some major brands have announced that they'll "ship Linux," but only Compaq seems to be doing anything. Go to Compaq's website, however and they tell you how to get Linux from RedHat -- to install on top of the copy of Windows that they'll install on your machine.
Of course, you shouldn't have to pay for that copy, because the Windows End User License Agreement (EULA) says that you can get your money back if you refuse the license. Just try. Many have, only a few have succeeded after months and months of trying.
Before you argue that these hapless PC manufacturers are just responding to market demand, think again (if, in fact, you think at all). With a stroke of a pen, Microsoft could crush Dell, or Compaq or Gateway. How? By raising the rate it charges each company for Windows. You wanna ship Linux? Fine, you lose your sweet deal on your volume Windows license. These companies have margins so tight that a few dollars difference in license fees could spell their death.
Compaq steps out of line and invests in RedHat and (surprise surprise) its profits drop like a rock. Wall Street conveniently blames Compaq's corporate acquisitions. Meanwhile, Dell is so deep in with Microsoft, you can't even order a Dell with Netscape on it, no matter how nicely you ask. Tip: buy Dell stock now. Sell it when Linux starts beating NT in corporate use surveys (notice I didn't say "if").
Get over it and work for Microsoft. Wait, you cant can you - your still in school.
Well, I, for one, haven't been in school for a long time. They let me out once I finally mastered the difference between "your" and "you're." I've turned down several invitations to work there and I'll turn down any more that come my way.
Microsoft is teetering. When it falls, it will fall hard. When IBM screws up, it still has a dozen other legs on the ground, but Microsoft is nowhere near as large and diverse as IBM. When Windows 2000 turns out to be a dud (notice I didn't say "if"), then Microsoft's one and only leg will buckle and the giant will stumble.
Slashdot Mirror
- Most of the people i know in the "community" despise SPAM.
I'm sure that most of the people you know also think girls are icky.- The Internet is clogged with spam.
Yes, and unlike RedHat's mailing, Spam is indiscriminate. You get it because you have an email address and for no other reason. That's why it's annoying. I've never wanted to sell crap in my spare time, see hot shaved teens (well, not on a computer), and I've heard the Good News(tm) about Jesus(r) more times than I can remember.- I use all spamblock methods I can, and STILL get tons of the crap.
Yeah, me too. And y'know what? When some spam slips through, I hit the DEL key and get on with my life. But I guess a "life" is something I have that you don't. Well, that and pubic hair.- In short, I think it reflects poorly on RedHat.
Fine... and your smug pettiness reflects well on Debian? Unfortunately, smug pettiness seems de rigeur for people with debian.org addresses.Keep picking nits. The grownups have work to do.
- Some people's Linux boxes crash, some people's NT boxes crash.
...
My point is that seeing is believing.So what is your point exactly?
I've seen an NT box crash. I've never seen a Linux box crash. I've seen OS/2's GUI lock up (face it, who hasn't?) but I've never seen the machine actually go down. My point? NT sucks.
- You claim this property of an OS is a demonstration of lack of scalability. "UNIX == not scalable" if you follow your logical argument.
I strongly doubt you could follow anyone's logical argument, or for that matter, identify a logical argument were it presented to you by a team consiting of Socrates, Descartes and Lt. Data.You said OS/2 didn't have a security subsystem. It does and it's flexible. That's the argument. OS/2 is more scalable than NT in a variety of ways as is UNIX. In terms of security, they are less flexible architecturally. That may or may not be a problem.
NT does suck, though.
Why don't you use that blood sponge in your head to argue about something vaguely important on Slashdot.
- The threading system crashes constantly does it?
No, the whole OS does. The threading is just slow as dirt.- NT has a crappy GUI compared to OS/2
- NT is slower than OS/2
- NT is more bloated than OS/2 (perhaps its most notable accomplishment)
- NT is less stable than OS/2 (and everytime is gets nearly as stable, they release new brokenware)
- NT has at least four Java systems that run on it, none of which run as fast as IBM's for OS/2.
The list goes on...- OS/2 completely lacked a security subsystem, unfortunately.
OS/2 has a security API which allows you to add a security subsystem appropriate for the risk level of the system. If you have a low-risk system, it is not encumbered by a bloated and slow security system. If you have a high-security system, you can install a high-security security manager. This is called scalability, something OS/2 also does better than NT.Too bad you don't have a clue subsystem in which to install a clue.
- Try implementing some applications using some of the extensive multithread APIs in the NT OS
Yes, and those engineers work at IBM where they developed OS/2. Not only was that threading capability stolen from OS/2, but it was stolen badly. OS/2's threading is much faster and doesn't crash constantly.[API's listed]
the core of the OS is amazingly well thoughtout and designed by experienced software engineers.
- ...and then come back and feel embarrassed...
I wouldn't think of it! Please, the embarassment is all yours.On the other hand, Open Source projects are usually started because of an immediate need. There are millions of Linux users out there and their needs tend to cover quite a bit. I have yet to find something I needed to do that didn't already have an open source project going...
C'mon guys, help me out here.
Fluent in a dead language. When Nietzsche wrote about the Superman, did he have you in mind or what?!
- Perl code is always interpreted, just like all programming languages, including Java and C++.
... your firmware is doing that interpretation.
What if there's no firmware? You... uh... did know that not all processors have firmware? Right? You're not trying to argue a point outside your narrow and increasingly inconsequential sphere of expertise? You wouldn't do that, would you?- Your pop-culture
... references are completely lost on me...
Well, at least they're in good company. My brilliant insights are completely lost on you too.- I do not do television
... I pursue a long-forgotten diversion called the reading of books.
Fear not, I have not lost the ability to read, although your posts are inspiring me to try. I have also not become so narrowminded and stagnant that I can'n appreciate music, film, television, dance or any number of arts.You might try it some time.
Get out more.
-trp
P.S. I left you a typo to criticise! I'm try to be kind to the rhetorically handicapped.
- Converting source code into bytecode is compiling. Period.
Fine. It's compiling. I wrote several times (enough times for you to read it at least once) that "compiling" doesn't have a very precise definition. Nobody is going to argue with you that what you call compiling is compiling. I'm certainly not.- It matters not what's goingto be handling those bytecodes, be it a code generator or a bytecode interpreter.
Again (for what, the fourth time?), I'm not disagreeing with this. What we were debating was whether Perl is "interpreted" or "compiled." In the likely case that your memory is as defective as the rest of your cognitive aperati, the important point of the original poster was that Perl is interpreted. You haven't really refuted that; all you've done is establish that "compile" and "interpret" are not mutually exclusive. Don't pull a muscle patting yourself on the back.For the last time: if the bytecode is not loaded into the CPU in an instruction fetch, it's being interpreted. Period. Even you, Lord God Price of Perl, use the words "bytecode interpreter."
You can use the word "compile" any way you want. You're not going to change the fact that Perl is interpreted.
You are sooooooo cool; when's your guest spot of "Friends"?
Yes, and I'll go further: even if the picoJava chip didn't exist, the fact that you could create one would be sufficient. I don't think a "picoPerl" chip could be designed, much less fabricated.
That means that all I'll have to do to make the Perl thingie-that-wishes-it-were-a-compiler into a true compiler, is, ... wave my magic wand and create a chip that happens to directly use the Perl bytecodes as its native instructions.
Yes, that's what I said. Should I say it again? Would that help?
Meanwhile, get a really good wand, Tom 'cause it will take some powerful magic to implement Perl in silicon. Gosling designed Java to be implementable in an embedded computer. Wall had no such plans with Perl and I don't think it's possible. Of course, you've made it clear to anyone still reading this thread that I'm a numbskull who knows nothing of the true "Computer Sciences", so post your schematic post haste and make me the laughingstock of slashdot.
Because I can already convert the Perl bytecodes into something to feed a C compiler...
If you want to call a Perl-to-native process "compiling," I'll be in agreement. Most of the time, however, Perl is interpreted by a "perl.exe". Again, you seem to be the only person who finds this distinction puzzling.
You have demonstrated... [blah blah blah]
So, when you're losing an argument, you retreat into "my thesaurus can beat up your thesaurus"? Pathetic.
No, it is a compiler the way everyone says it is, you smug bastard.
Everyone (meaning anyone with enough of a clue to be making these kinds of statements) says that javac compiles Java into bytecode for a Java machine. Pretty much nobody has a machine designed to run Java, so the bytecode is interpreted by JVMs which are compiled to run on real machines. Again, nobody seems to have a problem with this, except you.
And, again, the problem is that "compile" does not have a strict definition. Maybe you could formulate one and develop a new career promoting it. Instead of lecturing, teaching and writing on Perl (a subject of interest to many), you could lecture, teach and write on the proper use of the word "compile", which is a subject of interest to pretty much no one.
Personally, because I use Java so much, I tend to use the term "native" instead of "compiled", because "Java compiler" becomes a confusing term when people are trying to discuss Java-to-native versus Java-to-bytecode compilers.
Now, back to your little pet peeve. There is a chip, the picoJava chip, that runs bytecode native (that's bytecode compiled from Java source). There no picoPerl chip. You cannot run a Perl program unless you either have a Perl interpreter or you compile the Perl source to a native binary.
Again, here's another career opportunity, Tom. You could invent the Perl Virtual Machine and propose a hypothetical picoPerl chip and then, maybe people would start talking about compiling Perl the way they talk about compiling Java.
Until then, you will just have to suffer from compiler envy.
Gotcha.
Grow up.
The poster is right about ICMP, with regards to the RPF's. Dire warnings aside, a lot of people deny ICMP and work just fine.
A better solution is to program your choke router (that's ther router between your server(s) and the Internet) to block ICMP from passing into your network. The router can answer ICMP queries like MTU size, without exposing your server farm to cracker sniffing with ICMP.
You can also get fancy and deny specific ICMP. For example ICMP echo is not necessary, and ICMP netmask discovery gives out information you may not want to share. Neither of these steps break any legitimate network operations.
- If whatever is considered the executable form of the program (what you'd send to someone and say "run this") is not loaded directly into the processor (whatever the hardware designers of your system would consider "the CPU")
- via an instruction fetch cycle, then it is interpreted.
If you are unclear what exactly constitutes a CPU is or what differentiates an instruction fetch cycle from any other kind of cycle, RTF Hardware Docs.Start with yourself. I know what I mean. Most people know what I mean. I understand what you're getting at, but it's a total waste of time.
The root of the problem is that you can't really have a Science of computers for the same reason you can't have a Science of furniture. For example, everyone knows what a "couch" is, but can you precisely define it? Go ahead and try, but you'll leave some couches out of the definition or, inadvertently, include benches (which are not couches).
Same goes with "interpreted" or "compiled." Suffice to say that compiled code is fed via electrical signals into the processeor (whether that processor is one a chip, or a board). If the processor never performs an actual instruction fetch cycle on whatever is considered the program's "executable form" (such as bytecode for Java), then it's interpreted. I know, "ew, gross, hardware, reagisters, bus cycles! That's... hardware." Yeah, it is and maybe you shouldn't get so high and mighty when entering areas of computer "science" in which you have no expertise, Tom.
Yes, Tom, those of us who have actually designed CPUs know that there may be microcode (or even several levels of microcode) in the processor. That just means the definition isn't perfect, but it's servicable and everybody knows what it means.
Except you.
I can't believe you have time for this flame. Jave digging into your server-side mindshare?
- A language is interpreted if it's able to generate dynamic code and run it at run time.
Java can do this (you can generate new classes in bytecode on the fly), BASIC can do this (you can evaluated BASIC code in strings), Lisp can do this and non-compiled Perl can do this.Compiled C/C++ cannot do this. You can generate machine code on the fly, but you can't generate C/C++ code on the fly and run it at run time. It has to be compiled.
I'll defer to tchrist's clarifications of the perl side of this statement.
On the Java side, nobody said you had to run Java on a client. In fact, Java's most vital current development is on the server side. Some Perl bigots find this threatening because Java servlets are displacing Perl CGI, but Java and Perl have different strengths and weakness -- they are not interchangable and we should just stop trying to compare them.
AFAIK, the real crime of Mike Milken was his success in selling junk bonds
Unfortunately, this success was due, in part, with misrepresentation of the risk involved in buying junk bonds. As a result, a lot of due dilligence was corrupted and the American taxpayer had to help clean up the mess. He got what he deserved.
Century Plaza. 7PM show.
We waited all day to be the first in line for the 7PM show, and Simpson just waltzes right in using his celebrity powers. I don't know where he got the idea the rules don't apply to him...
Translation: I've never been on a project important enough to need a formal proposal, requirements analysis or a design document.
Keep up the good work. I've made some good money cleaning up spaghetti code written by code-cowboys who couldn't be bothered with sissified fancy-pants hoohah like documentation.
First of all, a lot of driver development was funded directly by IBM. The Linux equivalent are the user-written drivers (thanks, Don!) out there now.
But not all the drivers were written by IBM. In fact, you can still find OS/2 drivers on fairly recent products. What motivated vendors to write OS/2 drivers and why won't they write Linux drivers for a similarly-sized market?
The important answer is that hardware companies don't see the market as a collection of end users, but as a collection of buyers: small, medium and large. The large buyers dictate what the products look like.
If 20000 people write and say "Give us Linux," that is considerably less important than one person calling up and saying,"I want 20000 machines with Windows 98 on 19995 of them and Linux on 5 of them." If you look at the cost per sale and the cost of custom configurations, that volume buyer will get her Linux, but the 20000 individuals will get the run-around. In other words, the "Market Size" argument is bullshit; it's a sales volume issue, but more complex than "how many Linux boxen." In this example, a 20000-unit sale hinged on only 5 corporate Linux users, just as it once hinged on a small percentage of corporate OS/2 users.
So, back to the peripheral vendors: Let's say that Dell has just announced they are going to ship Linux (oh wait, they did). Now, they probably did this because a Fortune 500 CIO asked their VP of Sales "what [their] Linux strategy" is. Viola! Now they have one -- not for us, but for a small number of key volume clients.
But Dell doesn't make their own peripherals. They buy video chips, SCSI chips and so forth. So, having decided to support Linux, they go to their vendors and say,"So, what's your Linux strategy?" Now, even if Dell only sells one machine with Linux on it, it has to run. So are they going to buy millions of SCSI chips from the vendor who doesn't have a Linux driver? Of course not. So... do you want to be the one chip vendor who doesn't have a Linux driver? Duh, no.
Once upon a time, OS/2 had that "necessary bullet item" status. Vendors shelled out thousands of dollars to consultants (like me) to write the obligatory OS/2 driver. OS/2 flamed out of the marketplace and nowadays most vendors happily ignore the OS/2 market. Linux is hitting that "hot" phase right about now. Unlike OS/2, Linux doesn't have a parent company to abandon it, so it's unlikely to decrease in popularity.
Bottom line: expect and exponential growth in hardware support, particularly server stuff.
I guess you will have to sell your DELL stock quickly then:
Yes, yes, we've all read that "Dell plans to ship Linux." This isn't the event I mentioned, but let's pretend that your reading comprehension issn't severely impaired and I actually did say "sell when Dell offers Linux."
Dell is broken up into several divisions. They are strongly bound now, but diverging. Dell may be publicly announcing that they are offering Linux, but when, where and how? Will Linux even be mentioned on its online store? That's Dell Online, the second most profitable web site in the world and the highest-availability channel for buying Dell computers.
A lot of companies are offering Linux, but so far it's been to corporate clients through their corporate sales. It's almost impossible to get a consumer machine loaded with Linux, even from people who claim to support it. My point stands; this situation is just a bit more complex than I laid it out.
(When I booked plane travel to L.A. leaving on the 18th and returning on the red-eye on the 20th, the ticket agent guessed "Star Wars?" -- this is gonna be huge).
News Flash: The Vast Majority(tm) didn't decide either way.
"Like" implies favor. Favor implies choice. For most users, choice does not exist.
Perhaps you just emerged from a deep freeze, or your mom just let you on the Internet last week, so I'll fill you in on some news stories covered in depth here and... well, everywhere.
First of all, it's been well documented that you can't buy a PC from a major brand unless it has Windows on it. This includes IBM PC's and IBM makes OS/2, one of Window's supposed rivals. Have you ever heard someone say,"When the sales guy at Gateway asked me which OS I wanted, I chose Windows, because it's the best." No, you haven't and you never will, because no Gateway sales rep is going to ask that question. Some major brands have announced that they'll "ship Linux," but only Compaq seems to be doing anything. Go to Compaq's website, however and they tell you how to get Linux from RedHat -- to install on top of the copy of Windows that they'll install on your machine.
Of course, you shouldn't have to pay for that copy, because the Windows End User License Agreement (EULA) says that you can get your money back if you refuse the license. Just try. Many have, only a few have succeeded after months and months of trying.
Before you argue that these hapless PC manufacturers are just responding to market demand, think again (if, in fact, you think at all). With a stroke of a pen, Microsoft could crush Dell, or Compaq or Gateway. How? By raising the rate it charges each company for Windows. You wanna ship Linux? Fine, you lose your sweet deal on your volume Windows license. These companies have margins so tight that a few dollars difference in license fees could spell their death.
Compaq steps out of line and invests in RedHat and (surprise surprise) its profits drop like a rock. Wall Street conveniently blames Compaq's corporate acquisitions. Meanwhile, Dell is so deep in with Microsoft, you can't even order a Dell with Netscape on it, no matter how nicely you ask. Tip: buy Dell stock now. Sell it when Linux starts beating NT in corporate use surveys (notice I didn't say "if").
Get over it and work for Microsoft. Wait, you cant can you - your still in school.
Well, I, for one, haven't been in school for a long time. They let me out once I finally mastered the difference between "your" and "you're." I've turned down several invitations to work there and I'll turn down any more that come my way.
Microsoft is teetering. When it falls, it will fall hard. When IBM screws up, it still has a dozen other legs on the ground, but Microsoft is nowhere near as large and diverse as IBM. When Windows 2000 turns out to be a dud (notice I didn't say "if"), then Microsoft's one and only leg will buckle and the giant will stumble.