The "public outrage" has nothing to do with the trial itself. They have to do with the consequences if MS, even having won, tries to go back to it's bad old ways.
As for price gouging and predatory pricing, two points there. In the case of price gouging, a company can really only be guilty of it if they either control the market to the point where there is no alternative to paying their price or have colluded with everyone else in the market to bring about the same result. In the case of predatory pricing, an almost iron-clad defense is that the company is making a profit at that price. Predatory pricing charges aren't brought for just selling at a lower price than the competition, but at selling at a loss to drive competition out of the market.
As for bundling, again those charges are brought not just for offering products together, but for offering only a combination of products that are relatively independent and could be offered seperately. It's the difference between including IE on the Windows CD-ROM, and requiring that the user install IE when the OS doesn't need IE installed to run ( and don't give me the "part of the system DLLs" line, I can seperate routines out of shared libraries easily enough and MS themselves created the IBrowser COM interface that would let the OS use any browser that supported the relevant standards by merely complying with MS's own recommendations on interfacing with the browser ).
MS is charged with specific crimes. However, being guilty of those charges doesn't guarantee a conviction. MS in particular is very good at muddying the waters until the original points get lost. MS maintained their position by keeping everyone else out of the market by any means neccesary, but at this point even if they manage to avoid being found guilty of the charges brought against them they won't be able to go back to keeping everyone else out without making it unmistakeably clear that they were in fact guilty of exactly what the DOJ alleged.
Actually this analogy fails both parts. A CPU is required, certainly, but not a specific brand and speed of CPU. Removing the CPU renders the computer unusable, but only until you install another CPU. That's the whole point of having the CPU in a socket instead of soldered onto the motherboard. Saying that some CPU is required isn't equivalent to saying that a specific CPU is integrated into the MB.
Actually, even if they define the browser as a set of code, that doesn't help MS. If I take a handful of black marbles and mix them into a bin of white marbles, that doesn't make the black marbles inseperable from the white ones.
Real-world situation: I can take the BIND resolver libraries and drop them into libc. That doesn't make the BIND resolver routines part of libc, and the fact that they're both part of the same physical shared library doesn't change the fact that it's solely for convenience and I can seperate them again if I want to.
The ruling may wind up being irrelevant to the outcome. The big problem with MS has been that they have used their market share to bully everyone else, threatening to pull the Windows rug completely out from under anyone who even thinks about offering an alternative. The trial has changed that. While the trial goes on, MS cannot try their usual arm-twisting. Even after the trial, even if MS wins, they won't be able to go back to the way things were a year ago without triggering major outrage and probable legal problems. Whether the DOJ wins or loses, MS lost this one when the trial started.
First, an amazing amount of material travels in the clear that really shouldn't, especially corporate information. Even in government, I suspect a lot of information leaks in the clear, especially when a Dc-to-Virginia e-mail message may be routed by way of Chicago, San Diego and Dallas ( don't laugh, I've seen worse routes ).
Second, traffic analysis. How much can you put together by looking only at who talks to who and how often? Lots, and you don't need to decrypt a single message to get that.
What do we run? Netscape web servers on Solaris. When big news like the Starr report came out, all the servers at MSNBC running NT came crashing down under the load, but we didn't.
And I think you've hit it on the head right here. If Linux performs so poorly compared to NT, why is it that sites running NT-based web servers come crashing down when hit with the slashdot effect while Slashdot itself, running on Linux IIRC, stays up under at least a similar load.
"Under real-world conditions, if you drop a cannonball and a feather off a tall building the cannonball will hit the ground first. Any theory that predicts otherwise is useless for practical purposes regardless of how correct it is."
I never said that it would be free, what i meant is that it could force anyone with a private network to open it up to others. I myself wouldn't want to be forced to allow a customer (like AOL) that I know would suck off lots of bandwith. This bill would make it a crime to turn them away.
I disagree. From what I can read, all it does is mandate seperating the network from ISP services. In essence, if you have a network and provide ISP services, you must treat them as two seperate entities and if the network entity sells bandwidth at all it has to sell equally to everyone who wants it. And if AOL, for example, sucks down lots of bandwidth, you get to charge them for the network expansion needed to handle them. Just like phone service: the local telco cannot pick and choose which long-distance companies they'll allow their customers to use.
"has only limited commercially significant purpose or use other than to conceal such source or routing information; "
And masquerading cannot be forced under this, since it's purpose is not to conceal the source but to make the source and routing information appear correctly. After all, the real source and routing information for a masqueraded machine, by definition, shows IP addresses, host names and a route that does not exist on the internet.
Example: my home machine has IP address 192.168.171.1, hostname solitaire.silverglass.ttk. Were I not to masquerade it, the headers and routing information on mail coming from it would conceal the origin. The masquerading changes the mail to come from a place that does exist and where, if you send mail to it, the mail will get to me. I seriously doubt even lawyers would argue that changing headers to reflect the correct origin information constitutes concealing the origin.
Section 101-103 can be used to force a major provider to allow others to use their bandwith..kind of like the recent attempts by aol to force @home to open up their private network to them.
I don't think this is a valid objection. Certainly the provider has to allow other ISPs access to the bandwidth. As far as I can tell, though, it does not require the provider to give them free access. For example, where I live, USWest's DSL operates along a similar model to what this bill requires. USWest sells the DSL links, but you can select from any DSL-capable ISP. You have to pay USWest for the line regardless of which ISP you choose. The ISP has to pay USWest for the connection between the ISP's equiptment and USWest's ATM fabric, and for the bandwidth that ISP is using on USWest's network. All they're doing is seperating the DSL line from the ISP services at the other end of that line, and requiring the line provider to give anyone who can pay for it equal access to the lines. I can't see where this is fundamentally unfair.
As for section 104, I don't think you could make IP masquerading and the related tricks qualify under it as long as the modified version of the header was not itself false. My mail program, for example, needs the sender address modified from "tknarr@tknarr.users.xmission.com" to "tknarr@xmission.com". The original version is in fact false, the modified version is correct. Why would the modification to a correct header qualify as falsifying the header?
Yes, Sun was horribly out of spec. Another case of a company deciding that a feature was hurting performance without bothering to check why that feature was put in there in the first place. See also remove of "performance-robbing" slow start and exponential backoff in TCP stacks.
As for full-duplex, good switches eliminate collisions but only as long as all nodes are connected directly to a switch. Throw in some vanilla hubs and a bunch of older network cards and you're back to collisions ( albeit the collision domain is drastically reduced ). Dropped traffic also has an effect on throughput even though you aren't generating collisions, all those retransmits eat up bandwidth too.
The problem with Ethernet at high utilizations is collisions. Only one station on the Ethernet can transmit at a time, but due to signal delay the station can't tell when it starts to transmit whether another station is starting to transmit at the same time. When two try to talk at once you get a collision and they both have to stop, wait a short, random amount of time and try again. The more of your bandwidth you're using, the greater the chances of this happening. If it happens too much, utilization goes down because all the stations spend more of their time waiting for their last collision to clear than in actually transmitting. ATM, being effectively a point-to-point network at the physical level, doesn't suffer from collisions.
Most Ethernets seem to start having collision problems above 50% utilization. The worst case was a Sun implementation of Ethernet where the wait time after a collision was fixed at the minimum, resulting in the NICs dropping into lockstep when collisions started and network utilization dropping to 0%.
A good piece of advice ( unfortunately I forget the original attribution ):
"Find whatever it is that you like doing, then spend your life doing it. You may not make as much money, but you'll save more than that in antacid, asprin and therapist bills."
Of course you do need to make enough to live on, but past that you'll do better in the long run doing something that you enjoy rather than chasing the biggest paycheck. I think that's one correlation I see in the programmers who burn out: the ones who program for a paycheck are more likely to suffer burnout than the ones who program because they like programming.
#3 kills it. Someone send yet another MMF message to 1 million addresses culled from Usenet and the Web, and then when called on it they say "Everyone I sent it to can reasonably be assumed to be interested in a way to make money. The message was about making money. My post is not spam because all the recipients have a common thread of interest related to the message I send, hence it doesn't meet part 3 of your definition, and I dare you to prove otherwise.".
That's the general idea. The devil, as they say, is in the details, specifically making sure that you really don't eat up additional clock cycles very often. That's where I need to check the actual code before doing anything. 10-20 clock cycles every second is probably livable, the same number on every clock interrupt wouldn't be feasible.
I would tend to agree with you that the concepts you mention are important. I would disagree that a CS degree is the only, or even the best, way of getting them.
-Solid foundation in programming concepts
The problem with this one is that, from my own experience in a CS/CE program, you don't get a solid foundation. The canonical example is from a class in data structures and algorithms that I was forced to sit through. They spent an entire semester going through the theory behind and analysis of things like sorting algorithms. At the end, you knew everything there was to know about writing and using Quicksort vs. heap sort, and why you'd choose one over the other. Problem is, not once in the entire class did they ever touch on the single most important concept: why you should not be writing either Quicksort or heap sort in a program. In other classes they spent huge amounts of time on the correct ways of doing things to valid data, but not a single class spent any time on how to validate user input or other input data and how to handle invalid data, error conditions and the like. What I found was that, at least at the undergraduate and early post-grad levels, they spent all the time teaching things that were either too exotic to be useful or that you should not be doing yourself, while glossing over the dirty, messy, practical things that keep your code running when it leaves the nice, clean lab where all input is valid and you never run out of memory and enters the real world where input comes from a phone book falling on the keyboard and the disks crater in the middle of a critical database update.
-Knowledge of the processes of software development
Again, the degree programs tend to fail here. They teach the theory fine, but they gloss over or ignore completely the practical application of the processes to actual software projects. There's a world of difference between using a process on a 1000-line class project involving only one programmer, and applying the same process to a quarter-million-line point-of-sale system where you have 15 programmers in 3 groups working on it, the requirements change daily and bugfixes and minor enhancements get thrown in without warning.
-Curiosity and exploration of new technologies -Passion for the work -Rigorous and analytical thinking
What I've found most often is that the academic world works to eliminate these rather than teach and strengthen them. Students who embrace these concepts tend to argue with the professor ( and worse yet, prove him to be wrong in the process ), do things that the prof isn't prepared to deal with or doesn't want to deal with, "cheat" by making use of libraries or facilities that they know about but that the prof hasn't mentioned yet, get way ahead of the curriculum and generally be pains because the prof actually has to start thinking instead of just following the lesson plan.
ANSI/ISO C ( and C++ ) doesn't specify the signedness of time_t. However, existing practice uses negative time_t values to represent times before 1 Jan 1970. Switching time_t to unsigned wouldn't violate the standard but it would break lots of existing code ( which is the reason it isn't being done by the serious library developers ).
Is is becuase an increment on a long long takes longer than an increment on a long? And, if so, in this day and age of fast processors, does it really matter when compared to the future-proofing this would provide ?
A 64-bit increment takes several times as long on a 32-bit CPU as a 32-bit increment. And yes, even in this age of 500+MHz processors that makes a difference. I'm not that deep into that particular section of the code, but the clock-tick handler is probably one of the most-executed code paths in the kernel. While it's executing everything else on the system comes to a complete halt, so it's one of the hot-spots where cycles do count.
That said, I'm going to have to look to see whether there's a reasonably-low-overhead way of extending the 32-bit time to 64 bits on the i386 kernel. I use date classes that test out up through 31 Dec 9999, I might as well have a system time that's good until then too.
but can anyone honestly say that AMEX or NASDAQ could run their transactions on it? or serve a site like cnn.com?
One sanity check: what does Slashdot itself run on? Slashdot has to take at least as many hits as the sites being slashdotted, yet Rob's machine handles the load while sites like CNN are effectively shut down by it. This sounds to me like Linux is better at serving sites than whatever CNN is using.
The question is can we make enough money to justify the development and support costs.
Also ask whether you can make enough off of all Unix versions. Most of the APIs a typical app would use in Linux are not Linux APIs but standard APIs supported on almost all Unices. If it compiles on Linux and you didn't make assumptions about things like byte order and word size and stuff like that, there's a good chance that, with minimal work, the same code will compile on Solaris, AIX, HP-UX, Digital Unix, BSD etc. etc.. Tools like GNU autoconfig can help by doing the scut-work of figuring out what is supported on the platform you're compiling on this time so that, instead of writing code to platform X, you write based on "of capabilities X, Y and Z that would do the job, which are available on this platform?" ( eg. does this OS support select(), poll() or both? ). The GNU tools are prime examples of code that is designed to compile on multiple platforms, as some of those programs support literally an insane number of CPU/OS/version combinations.
The next question is do we try and support all the distributions, or just one (Red Hat).
Again, often you won't care about distribution. For example, for the C library calls, the question isn't "Is this RedHat or Debian?", but "Do I use libc5 or libc6/glibc2?" and "Do I need glibc 2.1.x or will 2.0.x work?". If, for example, glibc 2.0.7 works, then the same program should run fine on any distribution that uses glibc2 including RedHat and I believe the latest Debian.
File locations may get trickier, but the FSSTND and FHS are good guides. Use config files or environment variables to specify file locations ( with compiled-in paths based on FHS/FSSTND as fallback ), or depend on Unix facilities ( eg. use PATH via exec[l|v]p() or file-existence search to find executables instead of hard-coding their location ) and you can make adapting to a distribution's layout a trivial matter of making sure PATH is set correctly and a few lines in a config file are edited appropriately.
I have no problem with this idea, The small bit of network load wouldn't be to bad imho. (Still, you might want to make that: Clearly labeled AND smaller than 2048 bytes).
It wouldn't be a small network load even at 2048 bytes per message. Work the math. 10 million addresses. Say only 1 in 10 is sufficiently legal to cause network traffic ( either deliverable or needs to be relayed so that it won't be found to be undeliverable until after it's been transferred ). At 2K per message, you're looking at 2 gigabytes worth of traffic.
Somehow the entire burden of spam has to be shouldered by the spammers themselves, either by making it illegal or by having a reliable way to force them to pay for the don't want them to have to foot the bill for transport. And if you want the second, it needs to be after-the-fact and under the control of the recipient. I don't want to make a mailing list foot the bill because I subscribed to it, for example.
Rules #1 and #2 are a little impractical. Most of these crackers are pretty clueless, they could come from anywhere and they have no special interest in your system.
Yes, they're a pain. Problem is that, in amongst the script kiddies, there's likely to lurk one or two who actually know what they're doing. Scrubbing and reinstalling from clean copies is fast, but it doesn't leave you with any idea how the intruders got in. If they were SKs you're fine, but if they weren't they now know that you've seen them while you don't know that you have a threat still present.
And even with the SKs, tracking down how they got in lets you close up the holes so that more don't get in. If you don't close the holes, you're just going to keep getting hit. If you do close them, though, the number of intrusions drops off, leaving you more time for more useful work. That's where the payoff is: tracking down one cracker closes the holes that a couple of thousand of his cohorts could have used and you won't have to deal with them.
Tell me. A Linux user on my ISP is having problems with a 3Com 905B network card. After using Windows, it requires a power-cycle to work under Linux. The problem was finally traced to the D3-cold problem with PCI cards. Apparently MS has enough clout to get BIOS makers to actually change the way their PCI BIOS works so that, instead of the BIOS allocating resources per the PCI spec, the card is left disabled and it's up to the OS to enable it and allocate resources. Except for boot devices and sound cards, that is. Those do get handled by the BIOS. Boot devices should be obvious, and windows can't allocate the resources for sound cards. convenient that those are the only two exceptions, neh?
Rule #1: never reveal to an intruder that you know that he's there until after you've tracked down everything he's modified and are in a position to remove his additions. When you spotted his bot, you should have left it alone and started checking the rest of the system for modifications, removing the bot and closing him down only after you were sure you'd closed all the other holes he'd opened.
Rule #2: once you have removed an intruder, assume he'll be back and continue to monitor for him. If possible, stop all legit non-local ( network or modem ) access so that any such access must be the intruder. When he shows up, watch his every step without revealing yourself to him and see what he goes for.
Rule #3: always have backups. Always. If an intruder gets in it's almost certain that he'll destroy something, even if only by accident. You should always be in a position to let him destroy things, if for no other reason than to watch for what exploits or backdoors he uses in the process. I follow the old MS-DOS system rules: keep backups of data for a long enough time that you can get a clean one by going far enough back, and restore programs and such from clean distribution media or sources rather than depending solely on backups which could be corrupted by an intruder who's been in long enough.
Actually, it would be a good legal principle that company A cannot, as a condition of licensing company B to distribute A's product, restrict which other companies B can enter into agreements with, restrict or dictate the terms of those agreements, or include in their agreement penalties for B entering into an agreement with another company unless that other agreement caused B to violate their existing agreement with A.
In other words, "now that you've won, abandon the logic that won you the suit and help out Open Source advocates instead."
I don't think so. Yes, RMS's idea of publishing all the interface specs helps open source software. It also helps closed-source software as well, and relates directly to the browser-integration question.
Netscape's ( and other companies' ) complaint is that Microsoft can do things with their browser that everyone else is prevented or prohibited from doing. If the spec for the interface between IE and the OS is published completely, then it becomes possible for any browser to do everything IE does and to become indistinguishable from IE as far as the OS is concerned. This directly addresses the complaint, by making it possible for Netscape to compete on an even playing field with IE. Whether Netscape actually chooses to do so is another question, but if they don't it's not because they can't.
We have five (or fifty?) different window managers because there are different needs - but for a DnD protocol the number one need is that you can D anywhere.
We can have 5 or 50 window managers because they all speak the same protocol to apps. DnD should be the same: as long as the implementations follow the standard nothing should care what implementation the other end uses. Actually, I've wondered why apps didn't simply support X selections as intended instead of inventing a whole new protocol, but there may be issues I'm not aware of there. If the protocols worked through selections, theoretically you could have two apps that spoke two completely different DnD protocols talk to one another correctly because the underlying selections made sense to each of them. This is one of the places we lose Bill: the concept that one part of the system simply shouldn't care exactly which other part it's talking to, merely that that other part talks the same language.
As for growth, Linux has a likely minimum of a million or so users so we're not quite as bad as your example suggests. I think that growth rate discrepancy has to have Redmond worried.
Slashdot Mirror
The "public outrage" has nothing to do with the trial itself. They have to do with the consequences if MS, even having won, tries to go back to it's bad old ways.
As for price gouging and predatory pricing, two points there. In the case of price gouging, a company can really only be guilty of it if they either control the market to the point where there is no alternative to paying their price or have colluded with everyone else in the market to bring about the same result. In the case of predatory pricing, an almost iron-clad defense is that the company is making a profit at that price. Predatory pricing charges aren't brought for just selling at a lower price than the competition, but at selling at a loss to drive competition out of the market.
As for bundling, again those charges are brought not just for offering products together, but for offering only a combination of products that are relatively independent and could be offered seperately. It's the difference between including IE on the Windows CD-ROM, and requiring that the user install IE when the OS doesn't need IE installed to run ( and don't give me the "part of the system DLLs" line, I can seperate routines out of shared libraries easily enough and MS themselves created the IBrowser COM interface that would let the OS use any browser that supported the relevant standards by merely complying with MS's own recommendations on interfacing with the browser ).
MS is charged with specific crimes. However, being guilty of those charges doesn't guarantee a conviction. MS in particular is very good at muddying the waters until the original points get lost. MS maintained their position by keeping everyone else out of the market by any means neccesary, but at this point even if they manage to avoid being found guilty of the charges brought against them they won't be able to go back to keeping everyone else out without making it unmistakeably clear that they were in fact guilty of exactly what the DOJ alleged.
Actually this analogy fails both parts. A CPU is required, certainly, but not a specific brand and speed of CPU. Removing the CPU renders the computer unusable, but only until you install another CPU. That's the whole point of having the CPU in a socket instead of soldered onto the motherboard. Saying that some CPU is required isn't equivalent to saying that a specific CPU is integrated into the MB.
Actually, even if they define the browser as a set of code, that doesn't help MS. If I take a handful of black marbles and mix them into a bin of white marbles, that doesn't make the black marbles inseperable from the white ones.
Real-world situation: I can take the BIND resolver libraries and drop them into libc. That doesn't make the BIND resolver routines part of libc, and the fact that they're both part of the same physical shared library doesn't change the fact that it's solely for convenience and I can seperate them again if I want to.
The ruling may wind up being irrelevant to the outcome. The big problem with MS has been that they have used their market share to bully everyone else, threatening to pull the Windows rug completely out from under anyone who even thinks about offering an alternative. The trial has changed that. While the trial goes on, MS cannot try their usual arm-twisting. Even after the trial, even if MS wins, they won't be able to go back to the way things were a year ago without triggering major outrage and probable legal problems. Whether the DOJ wins or loses, MS lost this one when the trial started.
First, an amazing amount of material travels in the clear that really shouldn't, especially corporate information. Even in government, I suspect a lot of information leaks in the clear, especially when a Dc-to-Virginia e-mail message may be routed by way of Chicago, San Diego and Dallas ( don't laugh, I've seen worse routes ).
Second, traffic analysis. How much can you put together by looking only at who talks to who and how often? Lots, and you don't need to decrypt a single message to get that.
What do we run? Netscape web servers on Solaris. When big news like the Starr report came out, all the servers at MSNBC running NT came crashing down under the load, but we didn't.
And I think you've hit it on the head right here. If Linux performs so poorly compared to NT, why is it that sites running NT-based web servers come crashing down when hit with the slashdot effect while Slashdot itself, running on Linux IIRC, stays up under at least a similar load.
"Under real-world conditions, if you drop a cannonball and a feather off a tall building the cannonball will hit the ground first. Any theory that predicts otherwise is useless for practical purposes regardless of how correct it is."
I never said that it would be free, what i meant is that it could force anyone with a private network to open it up to others. I myself wouldn't want to be forced to allow a customer (like AOL) that I know would suck off lots of bandwith. This bill would make it a crime to turn them away.
I disagree. From what I can read, all it does is mandate seperating the network from ISP services. In essence, if you have a network and provide ISP services, you must treat them as two seperate entities and if the network entity sells bandwidth at all it has to sell equally to everyone who wants it. And if AOL, for example, sucks down lots of bandwidth, you get to charge them for the network expansion needed to handle them. Just like phone service: the local telco cannot pick and choose which long-distance companies they'll allow their customers to use.
"has only limited commercially significant purpose or use other than to conceal such source or routing information; "
And masquerading cannot be forced under this, since it's purpose is not to conceal the source but to make the source and routing information appear correctly. After all, the real source and routing information for a masqueraded machine, by definition, shows IP addresses, host names and a route that does not exist on the internet.
Example: my home machine has IP address 192.168.171.1, hostname solitaire.silverglass.ttk. Were I not to masquerade it, the headers and routing information on mail coming from it would conceal the origin. The masquerading changes the mail to come from a place that does exist and where, if you send mail to it, the mail will get to me. I seriously doubt even lawyers would argue that changing headers to reflect the correct origin information constitutes concealing the origin.
Section 101-103 can be used to force a major provider to allow others to use their bandwith..kind of like the recent attempts by aol to force @home to open up their private network to them.
I don't think this is a valid objection. Certainly the provider has to allow other ISPs access to the bandwidth. As far as I can tell, though, it does not require the provider to give them free access. For example, where I live, USWest's DSL operates along a similar model to what this bill requires. USWest sells the DSL links, but you can select from any DSL-capable ISP. You have to pay USWest for the line regardless of which ISP you choose. The ISP has to pay USWest for the connection between the ISP's equiptment and USWest's ATM fabric, and for the bandwidth that ISP is using on USWest's network. All they're doing is seperating the DSL line from the ISP services at the other end of that line, and requiring the line provider to give anyone who can pay for it equal access to the lines. I can't see where this is fundamentally unfair.
As for section 104, I don't think you could make IP masquerading and the related tricks qualify under it as long as the modified version of the header was not itself false. My mail program, for example, needs the sender address modified from "tknarr@tknarr.users.xmission.com" to "tknarr@xmission.com". The original version is in fact false, the modified version is correct. Why would the modification to a correct header qualify as falsifying the header?
Yes, Sun was horribly out of spec. Another case of a company deciding that a feature was hurting performance without bothering to check why that feature was put in there in the first place. See also remove of "performance-robbing" slow start and exponential backoff in TCP stacks.
As for full-duplex, good switches eliminate collisions but only as long as all nodes are connected directly to a switch. Throw in some vanilla hubs and a bunch of older network cards and you're back to collisions ( albeit the collision domain is drastically reduced ). Dropped traffic also has an effect on throughput even though you aren't generating collisions, all those retransmits eat up bandwidth too.
The problem with Ethernet at high utilizations is collisions. Only one station on the Ethernet can transmit at a time, but due to signal delay the station can't tell when it starts to transmit whether another station is starting to transmit at the same time. When two try to talk at once you get a collision and they both have to stop, wait a short, random amount of time and try again. The more of your bandwidth you're using, the greater the chances of this happening. If it happens too much, utilization goes down because all the stations spend more of their time waiting for their last collision to clear than in actually transmitting. ATM, being effectively a point-to-point network at the physical level, doesn't suffer from collisions.
Most Ethernets seem to start having collision problems above 50% utilization. The worst case was a Sun implementation of Ethernet where the wait time after a collision was fixed at the minimum, resulting in the NICs dropping into lockstep when collisions started and network utilization dropping to 0%.
A good piece of advice ( unfortunately I forget the original attribution ):
"Find whatever it is that you like doing, then spend your life doing it. You may not make as much money, but you'll save more than that in antacid, asprin and therapist bills."
Of course you do need to make enough to live on, but past that you'll do better in the long run doing something that you enjoy rather than chasing the biggest paycheck. I think that's one correlation I see in the programmers who burn out: the ones who program for a paycheck are more likely to suffer burnout than the ones who program because they like programming.
#3 kills it. Someone send yet another MMF message to 1 million addresses culled from Usenet and the Web, and then when called on it they say "Everyone I sent it to can reasonably be assumed to be interested in a way to make money. The message was about making money. My post is not spam because all the recipients have a common thread of interest related to the message I send, hence it doesn't meet part 3 of your definition, and I dare you to prove otherwise.".
That's the general idea. The devil, as they say, is in the details, specifically making sure that you really don't eat up additional clock cycles very often. That's where I need to check the actual code before doing anything. 10-20 clock cycles every second is probably livable, the same number on every clock interrupt wouldn't be feasible.
I would tend to agree with you that the concepts you mention are important. I would disagree that a CS degree is the only, or even the best, way of getting them.
-Solid foundation in programming concepts
The problem with this one is that, from my own experience in a CS/CE program, you don't get a solid foundation. The canonical example is from a class in data structures and algorithms that I was forced to sit through. They spent an entire semester going through the theory behind and analysis of things like sorting algorithms. At the end, you knew everything there was to know about writing and using Quicksort vs. heap sort, and why you'd choose one over the other. Problem is, not once in the entire class did they ever touch on the single most important concept: why you should not be writing either Quicksort or heap sort in a program. In other classes they spent huge amounts of time on the correct ways of doing things to valid data, but not a single class spent any time on how to validate user input or other input data and how to handle invalid data, error conditions and the like. What I found was that, at least at the undergraduate and early post-grad levels, they spent all the time teaching things that were either too exotic to be useful or that you should not be doing yourself, while glossing over the dirty, messy, practical things that keep your code running when it leaves the nice, clean lab where all input is valid and you never run out of memory and enters the real world where input comes from a phone book falling on the keyboard and the disks crater in the middle of a critical database update.
-Knowledge of the processes of software development
Again, the degree programs tend to fail here. They teach the theory fine, but they gloss over or ignore completely the practical application of the processes to actual software projects. There's a world of difference between using a process on a 1000-line class project involving only one programmer, and applying the same process to a quarter-million-line point-of-sale system where you have 15 programmers in 3 groups working on it, the requirements change daily and bugfixes and minor enhancements get thrown in without warning.
-Curiosity and exploration of new technologies
-Passion for the work
-Rigorous and analytical thinking
What I've found most often is that the academic world works to eliminate these rather than teach and strengthen them. Students who embrace these concepts tend to argue with the professor ( and worse yet, prove him to be wrong in the process ), do things that the prof isn't prepared to deal with or doesn't want to deal with, "cheat" by making use of libraries or facilities that they know about but that the prof hasn't mentioned yet, get way ahead of the curriculum and generally be pains because the prof actually has to start thinking instead of just following the lesson plan.
ANSI/ISO C ( and C++ ) doesn't specify the signedness of time_t. However, existing practice uses negative time_t values to represent times before 1 Jan 1970. Switching time_t to unsigned wouldn't violate the standard but it would break lots of existing code ( which is the reason it isn't being done by the serious library developers ).
Is is becuase an increment on a long long takes longer than an increment on a long? And, if so, in this day and age of fast processors, does it really matter when compared to the future-proofing this would provide ?
A 64-bit increment takes several times as long on a 32-bit CPU as a 32-bit increment. And yes, even in this age of 500+MHz processors that makes a difference. I'm not that deep into that particular section of the code, but the clock-tick handler is probably one of the most-executed code paths in the kernel. While it's executing everything else on the system comes to a complete halt, so it's one of the hot-spots where cycles do count.
That said, I'm going to have to look to see whether there's a reasonably-low-overhead way of extending the 32-bit time to 64 bits on the i386 kernel. I use date classes that test out up through 31 Dec 9999, I might as well have a system time that's good until then too.
but can anyone honestly say that AMEX or NASDAQ could run their transactions on it? or serve a site like cnn.com?
One sanity check: what does Slashdot itself run on? Slashdot has to take at least as many hits as the sites being slashdotted, yet Rob's machine handles the load while sites like CNN are effectively shut down by it. This sounds to me like Linux is better at serving sites than whatever CNN is using.
The question is can we make enough money to justify the development and support costs.
Also ask whether you can make enough off of all Unix versions. Most of the APIs a typical app would use in Linux are not Linux APIs but standard APIs supported on almost all Unices. If it compiles on Linux and you didn't make assumptions about things like byte order and word size and stuff like that, there's a good chance that, with minimal work, the same code will compile on Solaris, AIX, HP-UX, Digital Unix, BSD etc. etc.. Tools like GNU autoconfig can help by doing the scut-work of figuring out what is supported on the platform you're compiling on this time so that, instead of writing code to platform X, you write based on "of capabilities X, Y and Z that would do the job, which are available on this platform?" ( eg. does this OS support select(), poll() or both? ). The GNU tools are prime examples of code that is designed to compile on multiple platforms, as some of those programs support literally an insane number of CPU/OS/version combinations.
The next question is do we try and support all the distributions, or just one (Red Hat).
Again, often you won't care about distribution. For example, for the C library calls, the question isn't "Is this RedHat or Debian?", but "Do I use libc5 or libc6/glibc2?" and "Do I need glibc 2.1.x or will 2.0.x work?". If, for example, glibc 2.0.7 works, then the same program should run fine on any distribution that uses glibc2 including RedHat and I believe the latest Debian.
File locations may get trickier, but the FSSTND and FHS are good guides. Use config files or environment variables to specify file locations ( with compiled-in paths based on FHS/FSSTND as fallback ), or depend on Unix facilities ( eg. use PATH via exec[l|v]p() or file-existence search to find executables instead of hard-coding their location ) and you can make adapting to a distribution's layout a trivial matter of making sure PATH is set correctly and a few lines in a config file are edited appropriately.
I have no problem with this idea, The small bit of network load wouldn't be to bad imho. (Still, you might want to make that: Clearly labeled AND smaller than 2048 bytes).
It wouldn't be a small network load even at 2048 bytes per message. Work the math. 10 million addresses. Say only 1 in 10 is sufficiently legal to cause network traffic ( either deliverable or needs to be relayed so that it won't be found to be undeliverable until after it's been transferred ). At 2K per message, you're looking at 2 gigabytes worth of traffic.
Somehow the entire burden of spam has to be shouldered by the spammers themselves, either by making it illegal or by having a reliable way to force them to pay for the don't want them to have to foot the bill for transport. And if you want the second, it needs to be after-the-fact and under the control of the recipient. I don't want to make a mailing list foot the bill because I subscribed to it, for example.
Rules #1 and #2 are a little impractical. Most of these crackers are pretty clueless, they could come from anywhere and they have no special interest in your system.
Yes, they're a pain. Problem is that, in amongst the script kiddies, there's likely to lurk one or two who actually know what they're doing. Scrubbing and reinstalling from clean copies is fast, but it doesn't leave you with any idea how the intruders got in. If they were SKs you're fine, but if they weren't they now know that you've seen them while you don't know that you have a threat still present.
And even with the SKs, tracking down how they got in lets you close up the holes so that more don't get in. If you don't close the holes, you're just going to keep getting hit. If you do close them, though, the number of intrusions drops off, leaving you more time for more useful work. That's where the payoff is: tracking down one cracker closes the holes that a couple of thousand of his cohorts could have used and you won't have to deal with them.
Tell me. A Linux user on my ISP is having problems with a 3Com 905B network card. After using Windows, it requires a power-cycle to work under Linux. The problem was finally traced to the D3-cold problem with PCI cards. Apparently MS has enough clout to get BIOS makers to actually change the way their PCI BIOS works so that, instead of the BIOS allocating resources per the PCI spec, the card is left disabled and it's up to the OS to enable it and allocate resources. Except for boot devices and sound cards, that is. Those do get handled by the BIOS. Boot devices should be obvious, and windows can't allocate the resources for sound cards. convenient that those are the only two exceptions, neh?
Rule #1: never reveal to an intruder that you know that he's there until after you've tracked down everything he's modified and are in a position to remove his additions. When you spotted his bot, you should have left it alone and started checking the rest of the system for modifications, removing the bot and closing him down only after you were sure you'd closed all the other holes he'd opened.
Rule #2: once you have removed an intruder, assume he'll be back and continue to monitor for him. If possible, stop all legit non-local ( network or modem ) access so that any such access must be the intruder. When he shows up, watch his every step without revealing yourself to him and see what he goes for.
Rule #3: always have backups. Always. If an intruder gets in it's almost certain that he'll destroy something, even if only by accident. You should always be in a position to let him destroy things, if for no other reason than to watch for what exploits or backdoors he uses in the process. I follow the old MS-DOS system rules: keep backups of data for a long enough time that you can get a clean one by going far enough back, and restore programs and such from clean distribution media or sources rather than depending solely on backups which could be corrupted by an intruder who's been in long enough.
Actually, it would be a good legal principle that company A cannot, as a condition of licensing company B to distribute A's product, restrict which other companies B can enter into agreements with, restrict or dictate the terms of those agreements, or include in their agreement penalties for B entering into an agreement with another company unless that other agreement caused B to violate their existing agreement with A.
In other words, "now that you've won, abandon the logic that won you the suit and help out Open Source advocates instead."
I don't think so. Yes, RMS's idea of publishing all the interface specs helps open source software. It also helps closed-source software as well, and relates directly to the browser-integration question.
Netscape's ( and other companies' ) complaint is that Microsoft can do things with their browser that everyone else is prevented or prohibited from doing. If the spec for the interface between IE and the OS is published completely, then it becomes possible for any browser to do everything IE does and to become indistinguishable from IE as far as the OS is concerned. This directly addresses the complaint, by making it possible for Netscape to compete on an even playing field with IE. Whether Netscape actually chooses to do so is another question, but if they don't it's not because they can't.
We have five (or fifty?) different window managers because there are different needs - but for a DnD protocol the number one need is that you can D anywhere.
We can have 5 or 50 window managers because they all speak the same protocol to apps. DnD should be the same: as long as the implementations follow the standard nothing should care what implementation the other end uses. Actually, I've wondered why apps didn't simply support X selections as intended instead of inventing a whole new protocol, but there may be issues I'm not aware of there. If the protocols worked through selections, theoretically you could have two apps that spoke two completely different DnD protocols talk to one another correctly because the underlying selections made sense to each of them. This is one of the places we lose Bill: the concept that one part of the system simply shouldn't care exactly which other part it's talking to, merely that that other part talks the same language.
As for growth, Linux has a likely minimum of a million or so users so we're not quite as bad as your example suggests. I think that growth rate discrepancy has to have Redmond worried.