I don't know, I see the basic advice about security everywhere I look. You can't go to any security-related Web site, or even Microsoft's site, without hearing the basic common-sense rules I learned from other people in the BBS community back 25 years ago when I was in high school. Don't install software from sources you don't know and trust. Don't use software that downloads and runs stuff from external sources automatically. Put a hardware router with a firewall between your computer and the Internet. E-mail is text, don't try and treat it as anything else (or use a program that'll treat it as anything else) until after you've reviewed it to confirm that the non-text parts are really what you expect them to be. Don't trust e-mail just because of who the sender is, you know about all the viruses that use the address book to spread themselves and there's no guarantee the sender of that e-mail didn't get infected with one of 'em. None of that's rocket science, and it probably addresses 80% of the problems out there.
The core of the problem is responsibility, or a lack thereof.
Vendors aren't responsible for the results of the flaws in their programs. Worse, they aren't responsible for deliberate design decisions that make it impossible to secure systems. I make an analogy to automobiles. Auto makers aren't generally liable for defects in cars, unless the source of the defect goes beyond a simple mistake or defective part, but they are responsible for repairing those defects and can be sued if they refuse to do so. And they're liable for design decisions they make. Witness the Ford Pinto. The current state of software liability is akin to Ford claiming that, because they had a valid business reason for building the gas tank on the Pinto the way they did (it was cheaper, thus let them price the car cheaper), they cannot be held liable for the fires that happened as a direct result of their decision. The courts slapped Ford around for making that claim, why are software vendors not treated the same? I can live without strict liability for software flaws, but lack of liability for design decisions that directly lead to security problems is probably the biggest reason we still have problems.
And users aren't held responsible for their use of a computer. They treat it as some sort of plug-and-play device like a television or a radio: plug it in, turn it on and stop thinking about it. A computer isn't an appliance, you can't just ignore it after initial set-up. Again, cars make a good analogy. You can't just ignore a car's maintenance after you buy it, you need to put new tires, new brakes and such on it regularly. And car owners get held liable if they don't. If you wore your brakes out so they don't work anymore and didn't get them serviced, when you rear-end someone because you don't have any brakes you will be held responsible by the courts and the insurance. If you're running on bald tires because you don't think you should have to check and change anything, you're going to get ticketed by the cops at some point for unsafe mechanical condition and the car's registration will get suspended until you fix the problem. Sure it's a hassle and expense to keep maintaining all those things about a car that need maintained, but we don't accept that as an excuse for someone not maintaining them and causing damage or injury to others as a result. So why do we let computer users off the hook when they say "But I don't know anything about computers!".
Software vendors and computer users need to grow up. They've been both acting like spoiled 5-year-olds who were running in the house after being told not to, knocked over the china cabinet and broke everything in it, and now that Mom and Dad are standing there they're whining that they shouldn't have to own up to it and take their punishment. No dice.
What Microsoft has produced is not even a standard. Standards must specify everything, or reference other standards that specify everything. They can't reference applications.
I think that's exactly where MS has issues. And I don't think it's anything they deliberately try to do. It's been speculated that not even the Word developers have a spec for the Word.doc format. All they've got is a class that was given to them by someone else that can read and write.doc files, and a definition of the internal data structures that class produces and accepts. They confuse the specification with the application because to them the application is in fact the only specification they have. This also explains why they keep going off about source code when everybody else is talking about documenting file formats, because inside MS the only documentation on the file formats is the source code that handles them.
The article's incorrect. The RIAA isn't dropping the case. They can't, the defendant's already answered their complaint and once defendant's incurred costs plaintiff can't just wash their hands of the case. What they're doing is asking the judge to dismiss their case without prejudice (ie. they can refile the same case in the future). Given the judge's comments to this point I suspect he's going to be disinclined to do that, he'll give them a choice of having it dismissed with prejudice (can't refile) or not dismissing it at all.
It was protected as well. But it wasn't in his home, it was in the homes of the people he sent it to. He's claiming not that the government shouldn't be able to search his mail, but that the government shouldn't be able to search the mail of the people filing complaints about him even if they give permission for the search. In short, he's claiming that mail in someone else's mailbox belongs to him and he can control access to it. Which is wrong.
This was a class-3 code-signing certificate from Verisign, giving all the correct details for Microsoft but the request was coming from a bunch of crackers. How long, then, until the phishers figure out how to get EV-SSL certificates of their own?
Actually I think the bigger problem is that Microsoft and Verisign in the past have allowed a completely valid, high-grade signing certificate with Microsoft's own corporate identity to be issued to crackers (see http://www.pcworld.com/article/id,45284-page,1/art icle.html or the more authoritative http://www.microsoft.com/technet/security/bulletin /MS01-017.mspx for details). Note that a class-3 code-signing certificate was one of the more secure grades Verisign issues, it's not their standard e-mail-address-only ones. So how long until the bad guys start getting their own EV-SSL certificates and make the whole scheme not merely useless but advantageous to the phishers?
The proper response to that spokesman is "Well then, you won't mind lending us your passport for a minute, so we can copy it and put copies on sale in <district with notorious reputation>, will you?".
Some politicians simply need the problem made their personal problem before they'll see it.
He's not 30 years behind the times. He needs to access his e-mail from anywhere, regardless of connection. He might be working on a high-end workstation, a laptop or his PDA. It may not support remote graphics. He can't use a client that stores information locally, because he changes machines all the time. But for anything text, PuTTY or some sort of terminal emulation gives him full access to every one of his office machines from anywhere. Once he has that he doesn't need client software locally, he's got instant access to everything he's got installed on his main machines from anywhere in the world.
And face it, a resume is text. No pictures, no fancy backgrounds, plain text. None of the information you need to present in it requires anything more. Put it in plain-vanilla HTML and it'll look as good as the viewing platform lets it look, no matter what the viewing platform is. I call that an improvement over formats that demand the viewer have a certain minimum hardware.
Even "reliable sources" aren't reliable. Most e-mail viruses now don't spam random e-mail addresses to propagate, they scan the user's address book and send their malware-laden messages to those people. So just the fact that the e-mail's coming from someone you know and even that you're expecting a document from them doesn't mean you can assume that e-mail isn't from a virus carrying a dangerous payload.
There's one problem. His HR person reads resumes on a Mac using a 22" monitor with all the bells and whistles. He reads resumes on a system with exactly one font: fixed-pitch Courier, with pages a fixed 80 characters wide and 50 lines high. Both of them have to be impressed by the resume for it to get considered. When deciding that layout matters, think long and hard about your assumptions about how your layout will render. Then there's the question of fonts. Sure, that one font looks great on your system. But someone else may not have that font installed, so the render falls back on rescaling a crappy bitmapped font instead. Or they have the font installed but it's a really poor version because the good-looking version on their platform goes by another name for legal reasons. They've got their system set up to use the good-looking fonts, but your attempt to insure your document looks exactly like you want it to bypasses all their careful work and goes straight to the hideous-looking stuff. What a way to make a good first impression, no?
Myself, I consider that exact reproduction of layout is irrelevant. What matters is that the layout look good on whatever the reader's using. And on a resume you really don't need anything beyond what plain vanilla bog-standard HTML offers.
Why would banning Word documents bring your company to a halt? Word will open RTF files (for example) just as automatically as it will it's native format. It can save as RTF almost as easily as it's native format, it's at most 2-3 extra keystrokes once in the entire lifetime of the document. RTF handles all the text formatting, images and such that Word's native format does. The only things it doesn't support are the active content and such that malware uses, and I don't see that as a problem. So why should a block of Word documents have any effect whatsoever on a business?
I like the position my ISP's HR people take: "The posting said "No Word documents accepted.". The job's as a senior network engineer. It's going to require lots of detective work to troubleshoot obscure and arcane problems. If you can't figure out how to use Word's "Save As" to save in RTF or HTML, you are not qualified for the position. If you can't figure out that "No Word Documents accepted." means we won't be accepting Word documents, you aren't qualified for any position.".
For me, it's been the realization over the years that Microsoft has a dysfunctional corporate attitude. Dysfunctional? More like utterly sociopathic and psychotic. They believe there's only one acceptable state of affairs: Microsoft has 100% total control over any software market they want, and no competitors are permitted to exist.
Probably the clearest case is back when MS had just done IBM over on OS/2. Microsoft released the Win32S subsystem so that 16-bit Windows 3.1 could run newer 32-bit Windows NT binaries. IBM of course had their own Win32S subsystem in OS/2 as part of the Windows 3.1 compatibility. But Microsoft didn't want OS/2 to be compatible, so they kept changing the library link indexes in the Win32S libraries. They didn't change the API, they didn't change any functionality, they just changed the order the routines appeared in in the library link headers. From a technical standpoint there's absolutely no reason to do this, in fact there's good reason not to (for one thing, it's a fair amount of work for absolutely no technical gain). But doing it broke OS/2's Win32S compatibility. Programs compiled against the newest version of MS's Win32S libraries wouldn't run on OS/2 until IBM reverse-engineered the new index order and released an updated library of their own. And about a week after they did, MS would release another reordered Win32S library. This went on over the course of 6 months and 7-8 library releases, until IBM finally threw up their hands and gave up. Microsoft caused a lot of pain and annoyance to a lot of people to one and only one end: to insure that customers would not be able to choose OS/2 without unacceptable costs.
Microsoft hasn't changed in all the years since then. Their current OOXML deal is yet another Win32S game. They seem to believe that the only toys in the sandbox should be theirs, that all the other kids shouldn't be allowed to bring their own toys, and that the other kids shouldn't be allowed to go to any other sandbox to play. They're the worst kind of bully, and I've never liked bullies at all.
It's just more vendor-specific fields in the DHCP request and response, plus some ioctl() hooks into the network stack. Basically a CTCP client brings up a normal unrestricted TCP stack and sends it's info in fields in the DHCP request. The DHCP server sees the fields, analyzes them and sends back configuration info in the DHCP response. The client then interprets the configuration info and uses the CTCP API to tell the network stack to impose the rules the server sent.
Of course, you can see several gaping holes in this scheme already. As is only to be expected from Yet Another Harebrained Scheme Out Of Redmond.
I think it depends. Where I work we do multiple deployments: into the common development environment, into the QA system, into an internal user-test system, into a customer-test system and finally into production. The rule is that devs do the deployment into the CDE to work out the kinks. Devs and QA do the deployment into the QA so QA knows what's going on. Devs work with the IT staff doing the deployments into the two test systems so that IT knows how it goes and devs can work out any final issues that come up or that IT may have with the procedures. IT does the final deployment into production since they're responsible for those machines.
You can't just throw deployment on IT, it's the devs who wrote the software and know what needs done and who need to see what they missed so they can add procedures to cover it or fix whatever problem in the software caused the deployment glitch. You can't leave it to the devs to do production deployments, it's production fercryinoutloud, devs shouldn't be messing around directly in production except in dire emergencies. It's got to be a combination.
Not really. That's like saying that because it was my car, it was me driving it. There's nothing in the law that makes her responsible for the actions of other people in her household using her computer. Her ISP can hold her responsible, but nobody else (nobody else would be a party to the agreement between her and her ISP). Someone else in her household could be using the computer without her knowledge, or without her knowing exactly what they're doing with it. If I loan my car to a friend so they can go shopping, and I've no idea (and wouldn't reasonably know) that they intend to rob a bank, I'm not going to be on the hook for what they did. Same thing here.
The real problem for the RIAA is that it's fairly evident from the evidence presented that the lady did not download the music, her daughter did without her knowledge. The RIAA knows this. And the daughter, being a minor, is subject to certain protections. The judge ordered the RIAA to follow the legally-required procedures, and the RIAA refused to do so. That's what resulted in the original dismissal. This is likely to weigh heavily against the RIAA in this particular motion. When the plaintiff knows the defendant didn't do it, they know who did and they simply refuse to properly file suit against the correct defendant because it'd be inconvenient for them, the judge is likely to conclude that "But it could have been her." is not the correct answer.
Well, the standard for SJ is that there's either no facts in dispute or that no reasonable trier of fact could find other than a certain way. That gives a judge leeway to say "There's a dispute here, but the evidence is so lop-sided that there's only one conclusion a reasonable jury could come to.". See the SCO v. IBM contract dispute for an example. In this case, it's more about lack of evidence: has the RIAA presented a complete chain to suggest she might have been the user? If they haven't presented any credible evidence for a link in the chain, they can lose on summary judgment. In this case there's two weak points in their chain: Do they have a chain of custody for the screenshots? If they don't, then the ease of forging those in Photoshop gets all of them thrown out. Do they have any evidence at all to support the contention that she was either the person at the keyboard or knew who was and knew about and authorized that use? If they don't, then their side of the evidence scale is empty and the only way the preponderance of evidence wouldn't go against them is if the defense doesn't even deny the allegations. The attorney here is going after the second weak link. Unless the RIAA can show evidence that there wasn't anybody else who was in her house at those times to use the computer, they may lose on the grounds that while they've presented evidence that files were downloaded they haven't presented any evidence it was the defendant who downloaded them.
It's called "network address translation". Every home-networking router out there supports it. Even if they didn't, what AOL is saying in that letter is that a specific user account had those IP addresses leased at a particular time. That does not mean that a specific person was using that account. Usually the router or network connection's configured with the appropriate account information, and anyone using the computer will use that connection. The RIAA's claim isn't that the user account did the downloading and distributing, it's that a specific person did it. What they have to prove yet is that the person they're accusing was the person at the keyboard at the time or that they were otherwise legally responsible for the actions of whoever was (and the ISP TOS doesn't matter here since the RIAA isn't a party to that agreement).
It's the equivalent of the police charging me with reckless driving just because my car was involved. What they have to prove in court is not just that it was my car, but that it was me behind the wheel. If the car was stolen, or I loaned it to a friend and they were driving at the time, and I can prove this, everything they prove about who the car was registered to won't get them a conviction.
But I don't like the idea that the wheels of justice need to roll so fast that any and all evidence may be thrown out because it doesn't meet some arbitrary deadline.
All deadlines are arbitrary, and if there isn't a deadline then a baseless case could be drawn out for decades which just isn't reasonable or fair. The problem is that IBM didn't dump a bunch of stuff on SCO at the last minute. SCO got everything they asked for 2 to 3 years ago. They've had literally years to search the material to find evidence to support their case. After all that time they still don't have any evidence, so now SCO's the one trying to dump new claims in after the last minute. At some point the judge has to say "Enough is enough. You've had plenty of time, put your cards on the table and let's move on to seeing who's got the stronger hand.". SCO's problem is simply that they've got 10-high garbage in their hand while IBM's already got 3 kings showing.
Actually Magistrate Wells threw out none of SCO's claims. Every claim they made remains in the case, which is why her motion is non-dispositive. What she did was throw out the evidence SCO was trying to introduce to support their claims, on the grounds that they were ordered to produce it by a certain deadline, they had it in hand and could have easily produced it (according to their own statements), and they willfully refused to produce it. Having so failed to produce it in a timely manner, they're not allowed to use it now that it's too late for IBM to respond to it without prejudice. This leaves their claims with nothing to support them, which means they'll fall to a summary judgement motion by IBM (which is already in progress).
Both right, but Joel missed some of the point
on
You Call This Agile?
·
· Score: 0
Joel's right, software developers should be able to context-switch. But he misses the point of Dmitri's article. Pulling Sarah off the project she's on will have costs, not just in the context-switch overhead but in the disruption pulling her off will cause in projects already scheduled and in progress. The project manager wants the benefits of having her work on the customer request, but is he going to also accept responsibility for those costs? I've been in the situation Dmitri describes, and all too often the answer is a resounding "No.". Dmitri seems to simply be suggesting that those costs have to be taken into consideration.
I got that from the way the earliest versions of the fork() function worked when I began programming on Unixes (specificially 2.1BSD, although we quickly upgraded to 2.3BSD).
Slashdot Mirror
I don't know, I see the basic advice about security everywhere I look. You can't go to any security-related Web site, or even Microsoft's site, without hearing the basic common-sense rules I learned from other people in the BBS community back 25 years ago when I was in high school. Don't install software from sources you don't know and trust. Don't use software that downloads and runs stuff from external sources automatically. Put a hardware router with a firewall between your computer and the Internet. E-mail is text, don't try and treat it as anything else (or use a program that'll treat it as anything else) until after you've reviewed it to confirm that the non-text parts are really what you expect them to be. Don't trust e-mail just because of who the sender is, you know about all the viruses that use the address book to spread themselves and there's no guarantee the sender of that e-mail didn't get infected with one of 'em. None of that's rocket science, and it probably addresses 80% of the problems out there.
The core of the problem is responsibility, or a lack thereof.
Vendors aren't responsible for the results of the flaws in their programs. Worse, they aren't responsible for deliberate design decisions that make it impossible to secure systems. I make an analogy to automobiles. Auto makers aren't generally liable for defects in cars, unless the source of the defect goes beyond a simple mistake or defective part, but they are responsible for repairing those defects and can be sued if they refuse to do so. And they're liable for design decisions they make. Witness the Ford Pinto. The current state of software liability is akin to Ford claiming that, because they had a valid business reason for building the gas tank on the Pinto the way they did (it was cheaper, thus let them price the car cheaper), they cannot be held liable for the fires that happened as a direct result of their decision. The courts slapped Ford around for making that claim, why are software vendors not treated the same? I can live without strict liability for software flaws, but lack of liability for design decisions that directly lead to security problems is probably the biggest reason we still have problems.
And users aren't held responsible for their use of a computer. They treat it as some sort of plug-and-play device like a television or a radio: plug it in, turn it on and stop thinking about it. A computer isn't an appliance, you can't just ignore it after initial set-up. Again, cars make a good analogy. You can't just ignore a car's maintenance after you buy it, you need to put new tires, new brakes and such on it regularly. And car owners get held liable if they don't. If you wore your brakes out so they don't work anymore and didn't get them serviced, when you rear-end someone because you don't have any brakes you will be held responsible by the courts and the insurance. If you're running on bald tires because you don't think you should have to check and change anything, you're going to get ticketed by the cops at some point for unsafe mechanical condition and the car's registration will get suspended until you fix the problem. Sure it's a hassle and expense to keep maintaining all those things about a car that need maintained, but we don't accept that as an excuse for someone not maintaining them and causing damage or injury to others as a result. So why do we let computer users off the hook when they say "But I don't know anything about computers!".
Software vendors and computer users need to grow up. They've been both acting like spoiled 5-year-olds who were running in the house after being told not to, knocked over the china cabinet and broke everything in it, and now that Mom and Dad are standing there they're whining that they shouldn't have to own up to it and take their punishment. No dice.
What Microsoft has produced is not even a standard. Standards must specify everything, or reference other standards that specify everything. They can't reference applications.
I think that's exactly where MS has issues. And I don't think it's anything they deliberately try to do. It's been speculated that not even the Word developers have a spec for the Word .doc format. All they've got is a class that was given to them by someone else that can read and write .doc files, and a definition of the internal data structures that class produces and accepts. They confuse the specification with the application because to them the application is in fact the only specification they have. This also explains why they keep going off about source code when everybody else is talking about documenting file formats, because inside MS the only documentation on the file formats is the source code that handles them.
The article's incorrect. The RIAA isn't dropping the case. They can't, the defendant's already answered their complaint and once defendant's incurred costs plaintiff can't just wash their hands of the case. What they're doing is asking the judge to dismiss their case without prejudice (ie. they can refile the same case in the future). Given the judge's comments to this point I suspect he's going to be disinclined to do that, he'll give them a choice of having it dismissed with prejudice (can't refile) or not dismissing it at all.
It was protected as well. But it wasn't in his home, it was in the homes of the people he sent it to. He's claiming not that the government shouldn't be able to search his mail, but that the government shouldn't be able to search the mail of the people filing complaints about him even if they give permission for the search. In short, he's claiming that mail in someone else's mailbox belongs to him and he can control access to it. Which is wrong.
Only one response needed: http://www.microsoft.com/technet/security/bulletin /MS01-017.mspx
This was a class-3 code-signing certificate from Verisign, giving all the correct details for Microsoft but the request was coming from a bunch of crackers. How long, then, until the phishers figure out how to get EV-SSL certificates of their own?
Actually I think the bigger problem is that Microsoft and Verisign in the past have allowed a completely valid, high-grade signing certificate with Microsoft's own corporate identity to be issued to crackers (see http://www.pcworld.com/article/id,45284-page,1/art icle.html or the more authoritative http://www.microsoft.com/technet/security/bulletin /MS01-017.mspx for details). Note that a class-3 code-signing certificate was one of the more secure grades Verisign issues, it's not their standard e-mail-address-only ones. So how long until the bad guys start getting their own EV-SSL certificates and make the whole scheme not merely useless but advantageous to the phishers?
The proper response to that spokesman is "Well then, you won't mind lending us your passport for a minute, so we can copy it and put copies on sale in <district with notorious reputation>, will you?".
Some politicians simply need the problem made their personal problem before they'll see it.
He's not 30 years behind the times. He needs to access his e-mail from anywhere, regardless of connection. He might be working on a high-end workstation, a laptop or his PDA. It may not support remote graphics. He can't use a client that stores information locally, because he changes machines all the time. But for anything text, PuTTY or some sort of terminal emulation gives him full access to every one of his office machines from anywhere. Once he has that he doesn't need client software locally, he's got instant access to everything he's got installed on his main machines from anywhere in the world.
And face it, a resume is text. No pictures, no fancy backgrounds, plain text. None of the information you need to present in it requires anything more. Put it in plain-vanilla HTML and it'll look as good as the viewing platform lets it look, no matter what the viewing platform is. I call that an improvement over formats that demand the viewer have a certain minimum hardware.
One word: VT100.
Even "reliable sources" aren't reliable. Most e-mail viruses now don't spam random e-mail addresses to propagate, they scan the user's address book and send their malware-laden messages to those people. So just the fact that the e-mail's coming from someone you know and even that you're expecting a document from them doesn't mean you can assume that e-mail isn't from a virus carrying a dangerous payload.
There's one problem. His HR person reads resumes on a Mac using a 22" monitor with all the bells and whistles. He reads resumes on a system with exactly one font: fixed-pitch Courier, with pages a fixed 80 characters wide and 50 lines high. Both of them have to be impressed by the resume for it to get considered. When deciding that layout matters, think long and hard about your assumptions about how your layout will render. Then there's the question of fonts. Sure, that one font looks great on your system. But someone else may not have that font installed, so the render falls back on rescaling a crappy bitmapped font instead. Or they have the font installed but it's a really poor version because the good-looking version on their platform goes by another name for legal reasons. They've got their system set up to use the good-looking fonts, but your attempt to insure your document looks exactly like you want it to bypasses all their careful work and goes straight to the hideous-looking stuff. What a way to make a good first impression, no?
Myself, I consider that exact reproduction of layout is irrelevant. What matters is that the layout look good on whatever the reader's using. And on a resume you really don't need anything beyond what plain vanilla bog-standard HTML offers.
Why would banning Word documents bring your company to a halt? Word will open RTF files (for example) just as automatically as it will it's native format. It can save as RTF almost as easily as it's native format, it's at most 2-3 extra keystrokes once in the entire lifetime of the document. RTF handles all the text formatting, images and such that Word's native format does. The only things it doesn't support are the active content and such that malware uses, and I don't see that as a problem. So why should a block of Word documents have any effect whatsoever on a business?
I like the position my ISP's HR people take: "The posting said "No Word documents accepted.". The job's as a senior network engineer. It's going to require lots of detective work to troubleshoot obscure and arcane problems. If you can't figure out how to use Word's "Save As" to save in RTF or HTML, you are not qualified for the position. If you can't figure out that "No Word Documents accepted." means we won't be accepting Word documents, you aren't qualified for any position.".
For me, it's been the realization over the years that Microsoft has a dysfunctional corporate attitude. Dysfunctional? More like utterly sociopathic and psychotic. They believe there's only one acceptable state of affairs: Microsoft has 100% total control over any software market they want, and no competitors are permitted to exist.
Probably the clearest case is back when MS had just done IBM over on OS/2. Microsoft released the Win32S subsystem so that 16-bit Windows 3.1 could run newer 32-bit Windows NT binaries. IBM of course had their own Win32S subsystem in OS/2 as part of the Windows 3.1 compatibility. But Microsoft didn't want OS/2 to be compatible, so they kept changing the library link indexes in the Win32S libraries. They didn't change the API, they didn't change any functionality, they just changed the order the routines appeared in in the library link headers. From a technical standpoint there's absolutely no reason to do this, in fact there's good reason not to (for one thing, it's a fair amount of work for absolutely no technical gain). But doing it broke OS/2's Win32S compatibility. Programs compiled against the newest version of MS's Win32S libraries wouldn't run on OS/2 until IBM reverse-engineered the new index order and released an updated library of their own. And about a week after they did, MS would release another reordered Win32S library. This went on over the course of 6 months and 7-8 library releases, until IBM finally threw up their hands and gave up. Microsoft caused a lot of pain and annoyance to a lot of people to one and only one end: to insure that customers would not be able to choose OS/2 without unacceptable costs.
Microsoft hasn't changed in all the years since then. Their current OOXML deal is yet another Win32S game. They seem to believe that the only toys in the sandbox should be theirs, that all the other kids shouldn't be allowed to bring their own toys, and that the other kids shouldn't be allowed to go to any other sandbox to play. They're the worst kind of bully, and I've never liked bullies at all.
It's just more vendor-specific fields in the DHCP request and response, plus some ioctl() hooks into the network stack. Basically a CTCP client brings up a normal unrestricted TCP stack and sends it's info in fields in the DHCP request. The DHCP server sees the fields, analyzes them and sends back configuration info in the DHCP response. The client then interprets the configuration info and uses the CTCP API to tell the network stack to impose the rules the server sent.
Of course, you can see several gaping holes in this scheme already. As is only to be expected from Yet Another Harebrained Scheme Out Of Redmond.
I think it depends. Where I work we do multiple deployments: into the common development environment, into the QA system, into an internal user-test system, into a customer-test system and finally into production. The rule is that devs do the deployment into the CDE to work out the kinks. Devs and QA do the deployment into the QA so QA knows what's going on. Devs work with the IT staff doing the deployments into the two test systems so that IT knows how it goes and devs can work out any final issues that come up or that IT may have with the procedures. IT does the final deployment into production since they're responsible for those machines.
You can't just throw deployment on IT, it's the devs who wrote the software and know what needs done and who need to see what they missed so they can add procedures to cover it or fix whatever problem in the software caused the deployment glitch. You can't leave it to the devs to do production deployments, it's production fercryinoutloud, devs shouldn't be messing around directly in production except in dire emergencies. It's got to be a combination.
Not really. That's like saying that because it was my car, it was me driving it. There's nothing in the law that makes her responsible for the actions of other people in her household using her computer. Her ISP can hold her responsible, but nobody else (nobody else would be a party to the agreement between her and her ISP). Someone else in her household could be using the computer without her knowledge, or without her knowing exactly what they're doing with it. If I loan my car to a friend so they can go shopping, and I've no idea (and wouldn't reasonably know) that they intend to rob a bank, I'm not going to be on the hook for what they did. Same thing here.
The real problem for the RIAA is that it's fairly evident from the evidence presented that the lady did not download the music, her daughter did without her knowledge. The RIAA knows this. And the daughter, being a minor, is subject to certain protections. The judge ordered the RIAA to follow the legally-required procedures, and the RIAA refused to do so. That's what resulted in the original dismissal. This is likely to weigh heavily against the RIAA in this particular motion. When the plaintiff knows the defendant didn't do it, they know who did and they simply refuse to properly file suit against the correct defendant because it'd be inconvenient for them, the judge is likely to conclude that "But it could have been her." is not the correct answer.
Well, the standard for SJ is that there's either no facts in dispute or that no reasonable trier of fact could find other than a certain way. That gives a judge leeway to say "There's a dispute here, but the evidence is so lop-sided that there's only one conclusion a reasonable jury could come to.". See the SCO v. IBM contract dispute for an example. In this case, it's more about lack of evidence: has the RIAA presented a complete chain to suggest she might have been the user? If they haven't presented any credible evidence for a link in the chain, they can lose on summary judgment. In this case there's two weak points in their chain: Do they have a chain of custody for the screenshots? If they don't, then the ease of forging those in Photoshop gets all of them thrown out. Do they have any evidence at all to support the contention that she was either the person at the keyboard or knew who was and knew about and authorized that use? If they don't, then their side of the evidence scale is empty and the only way the preponderance of evidence wouldn't go against them is if the defense doesn't even deny the allegations. The attorney here is going after the second weak link. Unless the RIAA can show evidence that there wasn't anybody else who was in her house at those times to use the computer, they may lose on the grounds that while they've presented evidence that files were downloaded they haven't presented any evidence it was the defendant who downloaded them.
It's called "network address translation". Every home-networking router out there supports it. Even if they didn't, what AOL is saying in that letter is that a specific user account had those IP addresses leased at a particular time. That does not mean that a specific person was using that account. Usually the router or network connection's configured with the appropriate account information, and anyone using the computer will use that connection. The RIAA's claim isn't that the user account did the downloading and distributing, it's that a specific person did it. What they have to prove yet is that the person they're accusing was the person at the keyboard at the time or that they were otherwise legally responsible for the actions of whoever was (and the ISP TOS doesn't matter here since the RIAA isn't a party to that agreement).
It's the equivalent of the police charging me with reckless driving just because my car was involved. What they have to prove in court is not just that it was my car, but that it was me behind the wheel. If the car was stolen, or I loaned it to a friend and they were driving at the time, and I can prove this, everything they prove about who the car was registered to won't get them a conviction.
But I don't like the idea that the wheels of justice need to roll so fast that any and all evidence may be thrown out because it doesn't meet some arbitrary deadline.
All deadlines are arbitrary, and if there isn't a deadline then a baseless case could be drawn out for decades which just isn't reasonable or fair. The problem is that IBM didn't dump a bunch of stuff on SCO at the last minute. SCO got everything they asked for 2 to 3 years ago. They've had literally years to search the material to find evidence to support their case. After all that time they still don't have any evidence, so now SCO's the one trying to dump new claims in after the last minute. At some point the judge has to say "Enough is enough. You've had plenty of time, put your cards on the table and let's move on to seeing who's got the stronger hand.". SCO's problem is simply that they've got 10-high garbage in their hand while IBM's already got 3 kings showing.
Actually Magistrate Wells threw out none of SCO's claims. Every claim they made remains in the case, which is why her motion is non-dispositive. What she did was throw out the evidence SCO was trying to introduce to support their claims, on the grounds that they were ordered to produce it by a certain deadline, they had it in hand and could have easily produced it (according to their own statements), and they willfully refused to produce it. Having so failed to produce it in a timely manner, they're not allowed to use it now that it's too late for IBM to respond to it without prejudice. This leaves their claims with nothing to support them, which means they'll fall to a summary judgement motion by IBM (which is already in progress).
Joel's right, software developers should be able to context-switch. But he misses the point of Dmitri's article. Pulling Sarah off the project she's on will have costs, not just in the context-switch overhead but in the disruption pulling her off will cause in projects already scheduled and in progress. The project manager wants the benefits of having her work on the customer request, but is he going to also accept responsibility for those costs? I've been in the situation Dmitri describes, and all too often the answer is a resounding "No.". Dmitri seems to simply be suggesting that those costs have to be taken into consideration.
I didn't say vfork(), did I? vfork() came later, in 2.9BSD.
I got that from the way the earliest versions of the fork() function worked when I began programming on Unixes (specificially 2.1BSD, although we quickly upgraded to 2.3BSD).