Well, they can't know. But they'll say they've got a good-faith reason to believe so based on the complaint they got from their anonymous source. And yes, I'd say that particular provision has been tested. Not in software, but it's a common provision of a lot of contracts for one or both parties to be able to audit the other that way.
Now, of course, there's the interesting question of what happens if they come in, do their audit and find absolutely no software with their audit-agreement term in the EULA running (eg. a 100% F/OSS shop like Ernie Ball). At that point I'd have to think that, if you bill them for every penny their audit cost you including lost employee time and productivity, they'd have not a legal leg to stand on if they tried to refuse to pay. I'd say your chances of forcing them to pay in the end are very good. And if you gave them clear and convincing evidence before they came in that you had none of their members' software running (eg. a complete inventory accounting for every piece of hardware and every bit of software you had), you might stand a decent chance of also getting any court costs and fees awarded if you had to sue them for payment.
Because when you agree to the EULAs for software from their members, one term you agree to is that you will allow the copyright owner or it's authorized agent to audit you for license compliance and that you'll bear your costs in the matter regardless of the outcome. Either you permit the audit and eat the cost, or you admit in writing to violating the license.
Yes, catch-22. That's the price you pay for their software.
Uh, you are aware of how fork() worked back in the day, right? When I started using it it didn't even use copy-on-write, the child process shared the same page tables as it's parent. COW came along shortly after that, so I didn't ever have to get much involved with the details of keeping memory seperate. vfork() plays other games to avoid the overhead (in particular it doesn't exactly a new process until exec() gets called).
As for being heavyweight, perhaps compared to something like Sun green threads, yes. Compared to VMS or Windows process creation it was always much more light-weight because Unix just didn't have the process overhead. Clone the page tables, flag the pages as COW and you're pretty much there. In fact, as I noted, if you look in for instance Linux fork() and pthread_create() are in fact both simply thin wrappers that call the underlying clone() function. And green threads had their own issues, scheduling in particular (since they weren't KSEs).
Actually, on #1 I have a simple rule: if it involves an attorney, it's in writing. If an attorney tells me I don't need it in writing, I'm probably going to regret not having it in writing. Especially if that attorney's not on my payroll. It's the nature of things: if it was minor enough to not need a formal record, I probably wouldn't need to involve the attorney.
That doesn't, though, mean the world needs to be involved. In a situation like this the only people that IMO need to be involved at the start are the company's attorney (he's the authority on what the company's legally required to do) and the CFO (he's the one who needs to approve any expenditures I'm proposing). I want my summary to them of the state of software in the company, as well as their acknowledgement that I've given that summary to them, in writing for the record, and if they decide either there isn't a problem or they won't correct it I'll need that decision in writing too, but that's just so I don't have to worry about someone turning around later and saying "He didn't tell us about that." or "We didn't tell him to keep doing that.". I need a written record, but there's no need (yet) to make a big production out of it.
Now, if the CFO or company attorney want me to not fix the situation, to keep installing and using unlicensed software, and want to not have a written record of having instructed me to do that, then I need to consider other options up to and including tendering my immediate resignation.
First thing you need to do here is get the CFO and company attorney involved. The CFO because getting all those licenses is going to cost money, the company attorney because lack of licenses is a legal problem for the company. You also want the leverage: the CFO's not going to want to spend that much money if the company doesn't have to, the attorney is someone with authority to tell the CFO that the company does have to if it wants to keep the software available. You might also want to research news reports and have a few articles in hand less than a year old reporting on BSA raids of companies (to help convince the CFO that no, this isn't just a theoretical risk).
Before you go in, look over the F/OSS alternatives to the software in question. Ideally, have a laptop with it installed so you can show the CFO that no, it's not particularly inferior to the pirated commercial software. If he's already used OpenOffice to type up a memo and seen that it's just as easy to use and produces just as good a results as Word, he's going to be less sympathetic to spending lots of money on Word or to risking a BSA raid over it. This tends to look good to CxOs: you're identifying a real problem and presenting them with solutions to it that work while avoiding having to spend heart-attack-inducing amounts of money in the process. You'll still get screams from the users, but it'll go a lot smoother if you've got the executives on your side first.
Addendum: you can also play the service-provider card yourself. Suspend access to the post, contact the user who posted it with a copy of NCS Pearson's demand, have them retain an attorney and (if their attorney agrees with the argument) properly counter-notice you. Once you have that in hand, send a copy along with the contact information for the user's attorney and the information that attorney will need to identify which client is involved to NCS Pearson along with a statement that, per the 512(g) rules, you'll be restoring access to the material unless and until NCS Pearson notifies you that they've taken legal action against the poster. Then restore access to the post. If NCS Pearson files a John Doe suit and subpoenas you, move to quash the whole matter on the grounds that you've already given them that information and they should properly be suing the person they know is legally responsible and not involving you. If they try to get your service provider to act, your attorney should be able to shut that down with a similar argument.
Contact a competent attorney specializing in copyright and IP law. Trust only a lawyer working for you, never one working for the other guy. Then follow your lawyer's advice.
512(c)(3) sets forth the requirements for a valid DMCA takedown notice. One of those requirements, (vi), is for the person sending the notice to state under penalty of perjury that they're authorized by the copyright owner to send this notice. I see the letter they sent you never makes that statement. I'd respond to them noting this deficiency and that until it's corrected you can't take action without opening yourself to legal liability. I wouldn't be confrontational, simply request that they make that statement so that you can act without fear of being held liable yourself by the user and note that you'll be unable to comply with their request until it complies with the law itself. Being non-confrontational will help you if you do have to go before a judge, it'll show him that you're trying to comply with the requirements of the law and that it's NCS Pearson who're balking at doing the same. It'll also help take your own service provider out of the equation by giving them a good reason to refuse to take action. If it's not a valid DMCA takedown, they can't take action against you without leaving themselves possibly liable if the request turns out to be invalid, and gives them an excuse to say "Sorry, the law doesn't let us act until you've satisfied it's requirements.".
Having done the above, if your attorney agrees that you've got a valid argument, give NCS Pearson the benefit of the doubt about the validity of their notice and file a proper counter-notice per 512(g). This also takes your service provider out of the equation. Once they've received your counter-notice they have to cease interfering with access until NCS Pearson notifies them that they've actually filed a legal action against you or risk legal liability themselves. Again, it gives them a legal excuse to butt out of the whole matter. It also raises the bar for NCS Pearson, right now it's cheap for them to send demands but if you counter-notice they're going to have to actually involve a judge and the courts and it's going to get more expensive for them. Right now it's probably running on auto-pilot but once you counter-notice they'll have to decide whether it's going to be worth it to continue.
Unix didn't for a long time have lightweight preemptive threads because it had, from the very beginning, lightweight preemptive processes. I spent a lot of time wondering why Windows programmers were harping on the need for threads to do what I'd been doing for a decade with a simple fork() call. And in fact if you look at the Linux implementation, there are no threads. A thread is simply a process that happens to share memory, file descriptors and such with it's parent, and that has some games played with the process ID so it appears to have the same PID as it's parent. Nothing new there, I was doing that on BSD Unix back in '85 or so (minus the PID games).
That was, in fact, one of the things that distinguished Unix from VAX/VMS (which was in a real sense the predecessor to Windows NT, the principal architect of VMS had a big hand in the architecture and internals of NT): On VMS process creation was a massive, time-consuming thing you didn't want to do often, while on Unix process creation was fast and fairly trivial. Unix people scratched their heads at the amount of work VMS people put into keeping everything in a single process, while VMS people boggled at the idea of a program forking off 20 processes to handle things in parallel.
Part of the problem is that tools do very little to help break programs down into parallelizable tasks. That has to be done by the programmer, they have to take a completely different view of the problem and the methods to be used to solve it. Tools can't help them select algorithms and data structures. One good book related to this was one called something like "Zen of Assembly-Language Optimization". One exercise in it went through a long, detailed process of optimizing a program, going all the way down to hand-coding highly-bummed inner loops in assembly. And it then proceeded to show how a simple program written in interpreted BASIC(!) could completely blow away that hand-optimized assembly-language just by using a more efficient algorithm. Something similar applies to multi-threaded programming: all the tools in the world can't help you much if you've selected an essentially single-threaded approach to the problem. They can help you squeeze out fractional improvements, but to really gain anything you need to put the tools down, step back and select a different approach, one that's inherently parallelizable. And by doing that, without using any tools at all, you'll make more gains than any tool could have given you. Then you can start applying the tools to squeeze even more out, but you have to do the hard skull-sweat first.
And the basic problem is that schools don't teach how to parallelize problems. It's hard, and not everybody can wrap their brain around the concept, so teachers leave it as a 1-week "Oh, and you can theoretically do this, now let's move on to the next subject." thing.
There wasn't a business case for the automobile when it first came out, either. Nor for the airplane. But how many businesses today could operate without the overnight delivery offered by air freight and delivery vans? Not many.
Except that there is a business case for IPv6, mentioned right in the summary. customer demand. If customers want it, there's your business case right there: if we don't offer it, our customers will leave us for competitors who do offer it. "If we don't do it we'll lose more customers than we can afford to." has to be one of the more compelling business cases out there.
Like Harlan or hate him, he's got a point. Think about the position the movie studios, the record labels, the Author's Guild, all of them take when it comes to their stuff. All of them argue vehemently that you shouldn't be able to create anything containing their stuff, no matter how minor the use, without getting their permission and paying them for it. Well, like it or not, Harlan wrote the original script for that episode. He's in the credits. He's one of the copyright owners. By the studio's own argument, why shouldn't they have to get his permission and pay him exactly as they demand everybody else do for them?
Two reasons: convenience and hands-on. If the store has the item in stock, I can walk in and walk out 15 minutes later with what I need. That's a big deal when I've had something break and need a replacement Right Bloody Now. And in the store I can see the physical item, check connectors, check the length of cables, check the box, measure it, generally make sure it's exactly what I'm looking for. For some things that's not needed. For others, well, it's a lot easier to actually sit in the various models of chairs for instance and make sure they're comfortable instead of buying one and then finding out it just doesn't work for me.
Being Linux, you're likely using FireFox or one of it's builds (eg. Debian's IceWeasel). I recommend the AdBlock add-on, and possibly the NoScript add-on as well. In the process of blocking ads in general, AdBlock's going to get most of the porn ads as well. Set up bogofilter for e-mail filtering and you'll quickly get all the spam (including all the porn spam) diverted into a junk folder (Thunderbird has similar filtering built-in with it's junk-mail flagging feature, I use bogofilter mainly because I alternate between Thunderbird and Pine as my mail readers and want the junk-mail filtering to happen regardless of which one I'm using at the moment). That should take care of the majority of the problem. What's left will be search result spam, and those are mostly obvious from reading the result without having to visit the site to find out.
That's the nice thing here: there's no need to wonder, no need for conjecture, just compare the timestamps on his posts to the time the verdict was delivered based on the court record.
And if the timestamps show the entries were after the verdict was handed down, I think Stoam Holdings' attorneys should get hit with Rule 11 sanctions as an object lesson.
I don't think it's "social networking turning legal policy" so much as "social networking being relevant to motivation and impeachability". The judge in that case said, basically, that what the cop was saying on MySpace is just as relevant as anything else the cop might say. If the defendant would've brought in evidence of the cop regularly saying those same things to friends off-duty, or worse yet other cops on-duty, it would've been read as evidence that the cop isn't following the rules, undercutting his believability and the legal basis for his actions. All the judge said here was that "No, you don't get a free pass on what you say just because you said it on MySpace.". Which sounds reasonable to me.
Oh, and on the management side: remember that Linux is fully networked. Users don't need to log in to their local machine. One standard setup for users with limited needs (eg. a call center) is to have the local PC have only the X server and support tools installed, and the user logs in not to the PC but to a server back in the data center shared by all users. This massively simplifies system management: there's nothing on the PC that needs remote management, and as system manager you can manage the server by just logging in to it and managing it locally. Since X11's a network graphics protocol, it's also possible to log in on a local machine and then ssh/rsh/etc. to another machine to run applications using the local machine's display/keyboard/mouse. Hide the ssh command in an icon or menu item and have home directories shared via network mounts and the users may not even realize the application they're using is running on a server in a data center half-way across the continent.
Authenticating against AD should be easy. Samba can authenticate against your Windows domain, and PAM can be configured to authenticate users via Samba. Controlling what can be installed locally... at the system-wide level it's just a matter of installing only what you want installed. Make sure to point the package-management system at your own local package mirror so people can't go installing unapproved software or unapproved versions of approved software through it. For local installation (under the user's home directory), it's hard to completely prevent it but mounting/home noexec should keep the run-of-the-mill user from doing it. Lock down their login dot-files so they can't change their path and between that and not being able to run anything installed under their home directory only the most technically astute will find a way around it.
Filesystem mounts are already system-controlled, so they get what you want without you needing to do anything. Desktop preferences, screen settings and such... hard to control them because they're intended to be things users modify, but there's no real business reason to lock them down anyway. They don't affect anybody but that user, and the nasty stuff like malware disguised as screensavers is already dealt with by what you did to control running programs from their home directory. It's mostly not a problem like it is in Windows anyway.
Pushing applications to users... you completely misunderstand multi-user systems, then. Linux is a multi-user environment. The user != the machine. It makes no sense to talk about pushing an application to a user, because there may be 5000 users on a single machine each with a different set of roles. You can push applications to each user's personal desktop machine using the standard package-management software to install it, that's utterly trivial and needs nothing special beyond your standard software installation process.
Application preferences... again it's generally considered unneccesary to lock them down. It's trivial to install default initial files for applications when you create user's home directories, which gives them a consistent starting point. If you really need to lock them down, the usual method is to not let them own those files and give them read-only access to them. Remote management... in general once you've got SSH and XDMCP you can manage every machine in the company locally from your desk. Just SSH over to it or select it from the Chooser, log in and go. Or use SSH or rsync/rdist, to poke at it remotely or in automated scripts. Though you won't have firewalls and such to manage like you do in Windows, at least not on the individual machines.
I think you're still thinking of Linux like it's Windows. It isn't. The first big difference: Windows still has a lot of "the machine and the user are equivalent", while Linux has never in it's entire life had that concept (it was born out of Unix where hundreds if not thousands of users sharing a single machine was the norm, and one user moving between several machines and needing their home directory and settings to follow them was SOP). This one difference makes for a huge gulf between system management viewpoints.
Because the licenses in question are ones the MCP has already sold to customers. MCP sells license in 2007. Customer pays 1/3rd of fee in 2007. Customer will owe the remaining 2/3rds in 2 payments in 2008 and 2009. Customer goes bankrupt in January 2008 due to economy tanking. Microsoft tells MCP "Sorry, you owe the remaining 2/3rds of the license fee in 2 payments in 2008 and 2009. Pay up for 2008 please.".
The MCP buys the licenses from MS, and then resells them to their clients. Payments on them are done yearly over 3 years. If the client goes bankrupt part-way through, MS still expects to get it's payments for the license and considers the MCP to be on the hook for it since the MCP is who MS sold the license to.
Of course, while this is a great idea from a short-term financial standpoint (MS keeps it's immediate revenues coming in uninterrupted), in the long term and from a customer-relations standpoint it's an utter disaster. Any MCPs who stay in business are going to be looking long and hard at the potential costs of continuing to be an MCP vs. building their solutions on other platforms (their customers likely don't care what it's built on as long as it works, that's what they pay consultants for). But it's completely in character for MS, they've a long history of treating their customers and partners this way.
WSUS server: not needed. Any HTTP or FTP server can serve as a repository for most of the package-management systems in use in Linux distributions. Just point the PMS client's configuration file to your server and it'll update from it instead of the normal servers. Since you control what's on the server, you control the application versions. Cron jobs (running as root, not the user, so the user can't interfere with them) or the distribution's own automatic update system will handle auto-updating as usual.
Group-policy-driven software deployment: not needed. Automatic update will handle updates, and you can use rsync/rdist or ssh to install software remotely. You won't even need to ask the users to reboot to complete the installation in most cases.
Securing Firefox: look into the system-wide configuration. Seriously. You can configure add-ins and settings at both the user and the system level, and users can't override the system-level configuration. This is standard for Unix software.
Firewalling applications: Linux doesn't do that very well. But then it usually doesn't need to, the problems that caused application-level firewalling to be needed in Windows don't exist to nearly the same degree in Linux. Blocking execution of programs: mounting home directories "noexec" prevents users from installing and running their own programs (unless they're a bit technically inclined, in which case you're better off not trying to box them in by force).
Remote support and central installations: ssh, XDM and rsync/rdist. Linux is a multi-user system, the idea of multiple users being able to log in on the same machine is trivial. Being able to actually see what the user sees and manipulate thei desktop while they're using it is a bit harder, and frankly I tend to shy away from it for security reasons.
Partitioning: no, you don't, but they're a good idea. The basic idea is to separate things. Home directories are separate from the system software, so system upgrades and reinstalls don't affect user data. Things like the log directories and/tmp are separate from the main system so if a program goes rogue and dumps gigabytes of messages into the logs or gigabytes of junk into/tmp it won't kill the entire system.
Roaming home folders and offline access: Linux does network-mounted home directories easily, but keeping local copies for disconnected use isn't nearly as sophisticated. What I've seen most often is ignoring the whole configuration issue and using rsync/rdist to automatically synchronize a local and a central network-mounted directory holding the important data.
Screen savers and account management: screen savers can be forced to password-lock by the standard system-level configuration settings. Account management is usually done by using LDAP or NIS to hold the account database and managing that through the local tools for it. Network machines are simply configured via PAM to use the network account database instead of a local one. Usually machines have a minimal local account database to fall back on, and rsync/rdist against a central master copy is used to keep the machine up-to-date.
MCP isn't an individual certification. It's a vendor certification. It lets your consulting company sell licenses for the Microsoft products you use to develop your systems for customers, so for instance if a company calls you in to develop a trouble-ticketing system for them then as an MCP you can sell them your system plus the licenses for SQL Server, IIS, Windows desktops, the client access licenses, Exchange, Outlook and all the other software they'll need to set your system up. If you aren't an MCP then you can't sell them those licenses, they need to go talk to Microsoft or an MCP. Which do you think customers will prefer: going to you for the system and someone else for the software needed for the system, or going to an MCP who can offer the whole bundle as a single package?
When you move a computer to a different department you simply drag the computer in AD to the different OU and BAM! That computer now gets everything new with its policies. There's no bringing the computer in to the IT department and reloading its configuration with "Configuration A for Department B".
Um, what exactly does the physical location of the computer have to do with the user? What you're describing is simply user account configuration. If I'm in Accounting and I log in, my user login gets the Accounting settings and access. If I log in as a developer, I get developer settings and access. The machine is (or should be) utterly irrelevant to this. If I sit down at a machine in Accounting and log in using my developer login, I get my developer access as expected.
First rule of multi-user systems: the user != the machine. Much of the headache in Windows administration lies in trying to simulate a multi-user environment while treating the user and machine as equivalent. It makes things much easier in Unix if you just Don't Go There.
It's rather simple, really. Your "thin client" has a minimal system image with the X server and the few things it needs (eg. local fonts). It boots up into a runlevel that starts the X server in XDMCP query mode, either broadcasting or going directly to your primary application server. All user accounts are created on the primary application server. All applications are installed on the application server. Users log in to the application server via the xdm/gdm/kdm login box that'll be brought up by the XDMCP query. From there on it's the same old system we've had for 40+ years now: terminal hardware in front of you displaying applications running on the mainframe (server). The hardest part really is the initial stripping-down of a minimal Linux installation into a true thin-client setup with absolutely nothing not needed to boot the system and bring up the X server left.
If your docs describe something more complicated than setting up an X server in XDMCP query mode, they're probably doing it wrong.
I guess the first question is: what are you trying to accomplish? Are you trying to prevent users from installing additional software locally? Are you trying to insure that particular applications get particular preferences set and users are prevented from changing those settings? What? Just saying "lock down the desktops" doesn't say what you're trying to actually do.
Remember that Unix is, in large part, designed to work correctly without needing to be locked down. Much is controlled simply by the system-wide configuration files. The rest tends to be controlled on the server side, so that users simply can't do unacceptable things regardless of how they configure their local user account.
Slashdot Mirror
Well, they can't know. But they'll say they've got a good-faith reason to believe so based on the complaint they got from their anonymous source. And yes, I'd say that particular provision has been tested. Not in software, but it's a common provision of a lot of contracts for one or both parties to be able to audit the other that way.
Now, of course, there's the interesting question of what happens if they come in, do their audit and find absolutely no software with their audit-agreement term in the EULA running (eg. a 100% F/OSS shop like Ernie Ball). At that point I'd have to think that, if you bill them for every penny their audit cost you including lost employee time and productivity, they'd have not a legal leg to stand on if they tried to refuse to pay. I'd say your chances of forcing them to pay in the end are very good. And if you gave them clear and convincing evidence before they came in that you had none of their members' software running (eg. a complete inventory accounting for every piece of hardware and every bit of software you had), you might stand a decent chance of also getting any court costs and fees awarded if you had to sue them for payment.
Because when you agree to the EULAs for software from their members, one term you agree to is that you will allow the copyright owner or it's authorized agent to audit you for license compliance and that you'll bear your costs in the matter regardless of the outcome. Either you permit the audit and eat the cost, or you admit in writing to violating the license.
Yes, catch-22. That's the price you pay for their software.
Uh, you are aware of how fork() worked back in the day, right? When I started using it it didn't even use copy-on-write, the child process shared the same page tables as it's parent. COW came along shortly after that, so I didn't ever have to get much involved with the details of keeping memory seperate. vfork() plays other games to avoid the overhead (in particular it doesn't exactly a new process until exec() gets called).
As for being heavyweight, perhaps compared to something like Sun green threads, yes. Compared to VMS or Windows process creation it was always much more light-weight because Unix just didn't have the process overhead. Clone the page tables, flag the pages as COW and you're pretty much there. In fact, as I noted, if you look in for instance Linux fork() and pthread_create() are in fact both simply thin wrappers that call the underlying clone() function. And green threads had their own issues, scheduling in particular (since they weren't KSEs).
Actually, on #1 I have a simple rule: if it involves an attorney, it's in writing. If an attorney tells me I don't need it in writing, I'm probably going to regret not having it in writing. Especially if that attorney's not on my payroll. It's the nature of things: if it was minor enough to not need a formal record, I probably wouldn't need to involve the attorney.
That doesn't, though, mean the world needs to be involved. In a situation like this the only people that IMO need to be involved at the start are the company's attorney (he's the authority on what the company's legally required to do) and the CFO (he's the one who needs to approve any expenditures I'm proposing). I want my summary to them of the state of software in the company, as well as their acknowledgement that I've given that summary to them, in writing for the record, and if they decide either there isn't a problem or they won't correct it I'll need that decision in writing too, but that's just so I don't have to worry about someone turning around later and saying "He didn't tell us about that." or "We didn't tell him to keep doing that.". I need a written record, but there's no need (yet) to make a big production out of it.
Now, if the CFO or company attorney want me to not fix the situation, to keep installing and using unlicensed software, and want to not have a written record of having instructed me to do that, then I need to consider other options up to and including tendering my immediate resignation.
First thing you need to do here is get the CFO and company attorney involved. The CFO because getting all those licenses is going to cost money, the company attorney because lack of licenses is a legal problem for the company. You also want the leverage: the CFO's not going to want to spend that much money if the company doesn't have to, the attorney is someone with authority to tell the CFO that the company does have to if it wants to keep the software available. You might also want to research news reports and have a few articles in hand less than a year old reporting on BSA raids of companies (to help convince the CFO that no, this isn't just a theoretical risk).
Before you go in, look over the F/OSS alternatives to the software in question. Ideally, have a laptop with it installed so you can show the CFO that no, it's not particularly inferior to the pirated commercial software. If he's already used OpenOffice to type up a memo and seen that it's just as easy to use and produces just as good a results as Word, he's going to be less sympathetic to spending lots of money on Word or to risking a BSA raid over it. This tends to look good to CxOs: you're identifying a real problem and presenting them with solutions to it that work while avoiding having to spend heart-attack-inducing amounts of money in the process. You'll still get screams from the users, but it'll go a lot smoother if you've got the executives on your side first.
Addendum: you can also play the service-provider card yourself. Suspend access to the post, contact the user who posted it with a copy of NCS Pearson's demand, have them retain an attorney and (if their attorney agrees with the argument) properly counter-notice you. Once you have that in hand, send a copy along with the contact information for the user's attorney and the information that attorney will need to identify which client is involved to NCS Pearson along with a statement that, per the 512(g) rules, you'll be restoring access to the material unless and until NCS Pearson notifies you that they've taken legal action against the poster. Then restore access to the post. If NCS Pearson files a John Doe suit and subpoenas you, move to quash the whole matter on the grounds that you've already given them that information and they should properly be suing the person they know is legally responsible and not involving you. If they try to get your service provider to act, your attorney should be able to shut that down with a similar argument.
USC Title 17 section 512 is the relevant part. My thoughts:
Most supercomputers these days aren't single machines, they're clusters. Google "beowulf" for examples. See http://www.cbronline.com/news/linux_x86_clusters_take_over_top_500_supercomputer_ranking, they noticed the trend back in 2004.
Unix didn't for a long time have lightweight preemptive threads because it had, from the very beginning, lightweight preemptive processes. I spent a lot of time wondering why Windows programmers were harping on the need for threads to do what I'd been doing for a decade with a simple fork() call. And in fact if you look at the Linux implementation, there are no threads. A thread is simply a process that happens to share memory, file descriptors and such with it's parent, and that has some games played with the process ID so it appears to have the same PID as it's parent. Nothing new there, I was doing that on BSD Unix back in '85 or so (minus the PID games).
That was, in fact, one of the things that distinguished Unix from VAX/VMS (which was in a real sense the predecessor to Windows NT, the principal architect of VMS had a big hand in the architecture and internals of NT): On VMS process creation was a massive, time-consuming thing you didn't want to do often, while on Unix process creation was fast and fairly trivial. Unix people scratched their heads at the amount of work VMS people put into keeping everything in a single process, while VMS people boggled at the idea of a program forking off 20 processes to handle things in parallel.
Part of the problem is that tools do very little to help break programs down into parallelizable tasks. That has to be done by the programmer, they have to take a completely different view of the problem and the methods to be used to solve it. Tools can't help them select algorithms and data structures. One good book related to this was one called something like "Zen of Assembly-Language Optimization". One exercise in it went through a long, detailed process of optimizing a program, going all the way down to hand-coding highly-bummed inner loops in assembly. And it then proceeded to show how a simple program written in interpreted BASIC(!) could completely blow away that hand-optimized assembly-language just by using a more efficient algorithm. Something similar applies to multi-threaded programming: all the tools in the world can't help you much if you've selected an essentially single-threaded approach to the problem. They can help you squeeze out fractional improvements, but to really gain anything you need to put the tools down, step back and select a different approach, one that's inherently parallelizable. And by doing that, without using any tools at all, you'll make more gains than any tool could have given you. Then you can start applying the tools to squeeze even more out, but you have to do the hard skull-sweat first.
And the basic problem is that schools don't teach how to parallelize problems. It's hard, and not everybody can wrap their brain around the concept, so teachers leave it as a 1-week "Oh, and you can theoretically do this, now let's move on to the next subject." thing.
There wasn't a business case for the automobile when it first came out, either. Nor for the airplane. But how many businesses today could operate without the overnight delivery offered by air freight and delivery vans? Not many.
Except that there is a business case for IPv6, mentioned right in the summary. customer demand. If customers want it, there's your business case right there: if we don't offer it, our customers will leave us for competitors who do offer it. "If we don't do it we'll lose more customers than we can afford to." has to be one of the more compelling business cases out there.
Like Harlan or hate him, he's got a point. Think about the position the movie studios, the record labels, the Author's Guild, all of them take when it comes to their stuff. All of them argue vehemently that you shouldn't be able to create anything containing their stuff, no matter how minor the use, without getting their permission and paying them for it. Well, like it or not, Harlan wrote the original script for that episode. He's in the credits. He's one of the copyright owners. By the studio's own argument, why shouldn't they have to get his permission and pay him exactly as they demand everybody else do for them?
Two reasons: convenience and hands-on. If the store has the item in stock, I can walk in and walk out 15 minutes later with what I need. That's a big deal when I've had something break and need a replacement Right Bloody Now. And in the store I can see the physical item, check connectors, check the length of cables, check the box, measure it, generally make sure it's exactly what I'm looking for. For some things that's not needed. For others, well, it's a lot easier to actually sit in the various models of chairs for instance and make sure they're comfortable instead of buying one and then finding out it just doesn't work for me.
Being Linux, you're likely using FireFox or one of it's builds (eg. Debian's IceWeasel). I recommend the AdBlock add-on, and possibly the NoScript add-on as well. In the process of blocking ads in general, AdBlock's going to get most of the porn ads as well. Set up bogofilter for e-mail filtering and you'll quickly get all the spam (including all the porn spam) diverted into a junk folder (Thunderbird has similar filtering built-in with it's junk-mail flagging feature, I use bogofilter mainly because I alternate between Thunderbird and Pine as my mail readers and want the junk-mail filtering to happen regardless of which one I'm using at the moment). That should take care of the majority of the problem. What's left will be search result spam, and those are mostly obvious from reading the result without having to visit the site to find out.
That's the nice thing here: there's no need to wonder, no need for conjecture, just compare the timestamps on his posts to the time the verdict was delivered based on the court record.
And if the timestamps show the entries were after the verdict was handed down, I think Stoam Holdings' attorneys should get hit with Rule 11 sanctions as an object lesson.
I don't think it's "social networking turning legal policy" so much as "social networking being relevant to motivation and impeachability". The judge in that case said, basically, that what the cop was saying on MySpace is just as relevant as anything else the cop might say. If the defendant would've brought in evidence of the cop regularly saying those same things to friends off-duty, or worse yet other cops on-duty, it would've been read as evidence that the cop isn't following the rules, undercutting his believability and the legal basis for his actions. All the judge said here was that "No, you don't get a free pass on what you say just because you said it on MySpace.". Which sounds reasonable to me.
Oh, and on the management side: remember that Linux is fully networked. Users don't need to log in to their local machine. One standard setup for users with limited needs (eg. a call center) is to have the local PC have only the X server and support tools installed, and the user logs in not to the PC but to a server back in the data center shared by all users. This massively simplifies system management: there's nothing on the PC that needs remote management, and as system manager you can manage the server by just logging in to it and managing it locally. Since X11's a network graphics protocol, it's also possible to log in on a local machine and then ssh/rsh/etc. to another machine to run applications using the local machine's display/keyboard/mouse. Hide the ssh command in an icon or menu item and have home directories shared via network mounts and the users may not even realize the application they're using is running on a server in a data center half-way across the continent.
Authenticating against AD should be easy. Samba can authenticate against your Windows domain, and PAM can be configured to authenticate users via Samba. Controlling what can be installed locally... at the system-wide level it's just a matter of installing only what you want installed. Make sure to point the package-management system at your own local package mirror so people can't go installing unapproved software or unapproved versions of approved software through it. For local installation (under the user's home directory), it's hard to completely prevent it but mounting /home noexec should keep the run-of-the-mill user from doing it. Lock down their login dot-files so they can't change their path and between that and not being able to run anything installed under their home directory only the most technically astute will find a way around it.
Filesystem mounts are already system-controlled, so they get what you want without you needing to do anything. Desktop preferences, screen settings and such... hard to control them because they're intended to be things users modify, but there's no real business reason to lock them down anyway. They don't affect anybody but that user, and the nasty stuff like malware disguised as screensavers is already dealt with by what you did to control running programs from their home directory. It's mostly not a problem like it is in Windows anyway.
Pushing applications to users... you completely misunderstand multi-user systems, then. Linux is a multi-user environment. The user != the machine. It makes no sense to talk about pushing an application to a user, because there may be 5000 users on a single machine each with a different set of roles. You can push applications to each user's personal desktop machine using the standard package-management software to install it, that's utterly trivial and needs nothing special beyond your standard software installation process.
Application preferences... again it's generally considered unneccesary to lock them down. It's trivial to install default initial files for applications when you create user's home directories, which gives them a consistent starting point. If you really need to lock them down, the usual method is to not let them own those files and give them read-only access to them. Remote management... in general once you've got SSH and XDMCP you can manage every machine in the company locally from your desk. Just SSH over to it or select it from the Chooser, log in and go. Or use SSH or rsync/rdist, to poke at it remotely or in automated scripts. Though you won't have firewalls and such to manage like you do in Windows, at least not on the individual machines.
I think you're still thinking of Linux like it's Windows. It isn't. The first big difference: Windows still has a lot of "the machine and the user are equivalent", while Linux has never in it's entire life had that concept (it was born out of Unix where hundreds if not thousands of users sharing a single machine was the norm, and one user moving between several machines and needing their home directory and settings to follow them was SOP). This one difference makes for a huge gulf between system management viewpoints.
Because the licenses in question are ones the MCP has already sold to customers. MCP sells license in 2007. Customer pays 1/3rd of fee in 2007. Customer will owe the remaining 2/3rds in 2 payments in 2008 and 2009. Customer goes bankrupt in January 2008 due to economy tanking. Microsoft tells MCP "Sorry, you owe the remaining 2/3rds of the license fee in 2 payments in 2008 and 2009. Pay up for 2008 please.".
The MCP buys the licenses from MS, and then resells them to their clients. Payments on them are done yearly over 3 years. If the client goes bankrupt part-way through, MS still expects to get it's payments for the license and considers the MCP to be on the hook for it since the MCP is who MS sold the license to.
Of course, while this is a great idea from a short-term financial standpoint (MS keeps it's immediate revenues coming in uninterrupted), in the long term and from a customer-relations standpoint it's an utter disaster. Any MCPs who stay in business are going to be looking long and hard at the potential costs of continuing to be an MCP vs. building their solutions on other platforms (their customers likely don't care what it's built on as long as it works, that's what they pay consultants for). But it's completely in character for MS, they've a long history of treating their customers and partners this way.
WSUS server: not needed. Any HTTP or FTP server can serve as a repository for most of the package-management systems in use in Linux distributions. Just point the PMS client's configuration file to your server and it'll update from it instead of the normal servers. Since you control what's on the server, you control the application versions. Cron jobs (running as root, not the user, so the user can't interfere with them) or the distribution's own automatic update system will handle auto-updating as usual.
Group-policy-driven software deployment: not needed. Automatic update will handle updates, and you can use rsync/rdist or ssh to install software remotely. You won't even need to ask the users to reboot to complete the installation in most cases.
Securing Firefox: look into the system-wide configuration. Seriously. You can configure add-ins and settings at both the user and the system level, and users can't override the system-level configuration. This is standard for Unix software.
Firewalling applications: Linux doesn't do that very well. But then it usually doesn't need to, the problems that caused application-level firewalling to be needed in Windows don't exist to nearly the same degree in Linux. Blocking execution of programs: mounting home directories "noexec" prevents users from installing and running their own programs (unless they're a bit technically inclined, in which case you're better off not trying to box them in by force).
Remote support and central installations: ssh, XDM and rsync/rdist. Linux is a multi-user system, the idea of multiple users being able to log in on the same machine is trivial. Being able to actually see what the user sees and manipulate thei desktop while they're using it is a bit harder, and frankly I tend to shy away from it for security reasons.
Partitioning: no, you don't, but they're a good idea. The basic idea is to separate things. Home directories are separate from the system software, so system upgrades and reinstalls don't affect user data. Things like the log directories and /tmp are separate from the main system so if a program goes rogue and dumps gigabytes of messages into the logs or gigabytes of junk into /tmp it won't kill the entire system.
Roaming home folders and offline access: Linux does network-mounted home directories easily, but keeping local copies for disconnected use isn't nearly as sophisticated. What I've seen most often is ignoring the whole configuration issue and using rsync/rdist to automatically synchronize a local and a central network-mounted directory holding the important data.
Screen savers and account management: screen savers can be forced to password-lock by the standard system-level configuration settings. Account management is usually done by using LDAP or NIS to hold the account database and managing that through the local tools for it. Network machines are simply configured via PAM to use the network account database instead of a local one. Usually machines have a minimal local account database to fall back on, and rsync/rdist against a central master copy is used to keep the machine up-to-date.
MCP isn't an individual certification. It's a vendor certification. It lets your consulting company sell licenses for the Microsoft products you use to develop your systems for customers, so for instance if a company calls you in to develop a trouble-ticketing system for them then as an MCP you can sell them your system plus the licenses for SQL Server, IIS, Windows desktops, the client access licenses, Exchange, Outlook and all the other software they'll need to set your system up. If you aren't an MCP then you can't sell them those licenses, they need to go talk to Microsoft or an MCP. Which do you think customers will prefer: going to you for the system and someone else for the software needed for the system, or going to an MCP who can offer the whole bundle as a single package?
When you move a computer to a different department you simply drag the computer in AD to the different OU and BAM! That computer now gets everything new with its policies. There's no bringing the computer in to the IT department and reloading its configuration with "Configuration A for Department B".
Um, what exactly does the physical location of the computer have to do with the user? What you're describing is simply user account configuration. If I'm in Accounting and I log in, my user login gets the Accounting settings and access. If I log in as a developer, I get developer settings and access. The machine is (or should be) utterly irrelevant to this. If I sit down at a machine in Accounting and log in using my developer login, I get my developer access as expected.
First rule of multi-user systems: the user != the machine. Much of the headache in Windows administration lies in trying to simulate a multi-user environment while treating the user and machine as equivalent. It makes things much easier in Unix if you just Don't Go There.
It's rather simple, really. Your "thin client" has a minimal system image with the X server and the few things it needs (eg. local fonts). It boots up into a runlevel that starts the X server in XDMCP query mode, either broadcasting or going directly to your primary application server. All user accounts are created on the primary application server. All applications are installed on the application server. Users log in to the application server via the xdm/gdm/kdm login box that'll be brought up by the XDMCP query. From there on it's the same old system we've had for 40+ years now: terminal hardware in front of you displaying applications running on the mainframe (server). The hardest part really is the initial stripping-down of a minimal Linux installation into a true thin-client setup with absolutely nothing not needed to boot the system and bring up the X server left.
If your docs describe something more complicated than setting up an X server in XDMCP query mode, they're probably doing it wrong.
I guess the first question is: what are you trying to accomplish? Are you trying to prevent users from installing additional software locally? Are you trying to insure that particular applications get particular preferences set and users are prevented from changing those settings? What? Just saying "lock down the desktops" doesn't say what you're trying to actually do.
Remember that Unix is, in large part, designed to work correctly without needing to be locked down. Much is controlled simply by the system-wide configuration files. The rest tends to be controlled on the server side, so that users simply can't do unacceptable things regardless of how they configure their local user account.