In the old days, using BCC in emails you sent was considered a "stab in the back" strategy. It was considered fine to use it for mass email sending but not for specific emails you send to a specific group of people. Using CC was the prescribed strategy to adopt.
Quite correct, hence why I've seen at least one employer ban it outright.
Didn't stop people CC'ing in the chain of command as a means of stabbing someone in the back, just meant that the stab-ee knew about it straight away.
Breaking a contract is civil law - IANAL but I'm pretty sure the correct term for that is civil law, not contract law.
Thing is, most jurisdictions do have criminal law regarding unauthorised access to computer systems. Facebook's terms are pretty clear that you're the only person authorised to log in under your name. In which case, you could probably argue that giving someone else your password is essentially aiding and abetting.
Arguably, it's not necessary to go that far. There's only a handful of tier one carriers, if you can force them to stop routing all traffic within the US, you may not shut down the Internet in the US entirely but you'd definitely cripple it.
Millions of people manage to use encrypted systems every day for Internet banking or shopping. Encryption does not have to be hard.
What is hard is providing a user interface to a means of encryption so that the complications are reduced or eliminated while still maintaining some semblance of security. AFAICT, nobody's managed to do that in a fashion suitable for anyone to use on arbitrary streams of data that need to be encrypted and passed around as part of a batch process.
The way Facebook is designed (and, for that matter, its popularity) means you can't. Or at least, probably shouldn't.
The main reason why is the photo sharing feature. On facebook or not, there's a good change that quite a few photos of you have been made public (yes, including that embarrassing one from last year when you had a bit too much to drink), tagged your name against it and it's there for all to see. There have been instances of people losing their jobs because of photos on facebook - well, you could (at least in theory) lose your job because of a photo of you someone else put up even though you've never used the damn site.
About the only thing you can do to try and prevent this is to sign up, make sure any photos of you are tagged and associated with your login then either remove those tags yourself or set your privacy settings so photos including you aren't public. Until the next time Facebook change their privacy defaults - which they'll do all they like because the users aren't the customers.
It's the electronic equivalent of graffiti on the bridge over the main road into town saying "kiwimate is a tosser!" except it comes with photographic evidence and it's much more likely to get distributed to anyone around the world than a bridge is.
Something like that, yes. I hadn't heard of Sparkle, but it looks like it's roughly the right idea.
The reason it needs to be in the OS is because if it isn't, there's precious little chance of third-party software supporting it. Not only would it reduce these risks, but it could hook into Active Directory for enterprises.
Though existing companies providing network management software would probably have something to say about that.
I've been saying this for some time: Windows (and to a lesser extent OS X) needs an API so updates are centralised, configured and installed from a single interface.
OS X has the app store. Linux distributions have repositories. Both of these solve this problem very neatly, and it's a lot easier to keep everything up to date. But I don't think centralised distribution is necessary - just an API call so you can say to the operating system "this is the name of the application, this is an RSS feed where updates are published, this is the key with which updates will be signed, this is how frequently you should check for updates" would probably solve most of the problems.
The mess we have right now is the reason why there is always something on a PC that needs updating.
anything which can be explained by stupidity. Or, for that matter, planning.
I suspect it's rather simpler than "Micro$oft hates GPL!!11oneone", and has nothing to do with any particular hatred of the GPL and related licenses.
Let's say, for the sake of argument, you're building an apps store in the style of Apple. It's going to look all pretty, it's going be dead simple to download anything, people can submit apps, they go through an approval process, they go on the store. Installing is a matter of "click once", and that's about the only thing you're going to make visible to the end user.
You anticipate having thousands of apps sooner rather than later, so the complicated part isn't going to be the website. It's going to be putting together the business logic and processes that drive it.
The problem with something like the GPL is that all of a sudden, your process for accepting for approval, approval itself and distributing software suddenly becomes a hell of a lot more complicated because you now need to keep track of whether or not an application requires the source code to be made available. Remember the GPL applies to anyone distributing the software, so you can't just palm this back to the developer. You now need a separate interface to your apps store from the developer site which allows downloading source code where available, you need to keep track of which apps have which licenses - and you need to track which licenses specifically state "You must distribute source code".
Unless you took this into account when you designed the apps store and the processes behind it (which is likely if you're Google, but vanishingly unlikely if you're Microsoft), you now have a problem. Your entire process is set up on the assumption that you are under no obligation to distribute the source code for apps, this throws a spanner in the works. What is the cheapest, quickest, easiest solution?
1. Ban licenses which demand you distribute source code such as the GPL. 2. Go back and rewrite all your processes to account for licensing issues. Any software developed around those processes will also need changing.
TL;DR : More likely that Microsoft don't care enough about F/OSS to bother accounting for it in their processes for their app store.
Well, with Tivo you didn't buy their EPG. You bought the box but in order for it to be any use you subscribed to the EPG. Which might mean they'd get away with it - were it not for the fact that they offered one-off lifetime subscriptions for £120.
Having said all that, they're a business. And almost all business decisions can be boiled down to money.
Were I in Tivo's shoes, I'd have worked the arithmetic something like this:
Worst case scenario: Customer(s) take us to court, win, we're obliged to refund some proportion of their lifetime subscription. This isn't the US where you can sue for the loss at £120 then the "hurt feelings" at £1,000,000.
The only customers who are likely to make a fuss are those still using a lifetime subscription.
So, how many people with lifetime subscriptions are still using them? Should be easy enough to figure out, the boxes phone home every night to download their EPG. Which means there must be some means of authenticating the box or how else would you know that it was associated with a lifetime sub? Once you've worked out this number, let's call it N
Multiply N by the cost of the subscription (£120) and you've got an idea of the worst-case you'd be paying out - excluding legal fees. I would be astonished if that number is much more than, say, £120,000 - Tivo pulled out of the UK years ago, the only boxes which are affected are going to be getting on a bit now.
Okay, so how much does it cost to maintain the EPG service - including a pool of dialin modems, the servers and the software? This would be a service which every other PVR in the country is getting straight from Freeview/Cable/Satellite system and so the cost of running it is exclusive to your old product. I bet you anything you like it's expensive enough that even with the worst-case payout, it's still cheaper within three years to cancel the service.
If it's in an index-linked fund there's a good chance you'll wind up beating automated traders. 80% of the things that try to beat the market average fail, sometimes spectacularly.
Doubt it. It's not like you're going to cobble together the systems running a stock exchange from whatever you could find leftover in the warehouse.
Infinitely more likely that there's only a handful of software development houses with the expertise to develop stock exchange systems of this sort of size. (Which makes sense, as there's only a handful of big stock exchanges). Which means there's only a handful of companies that are going to be taken seriously if they bid for the contract.
Assuming there's only, say, three such development companies, only one of them provides a product that runs under Windows and that one's being turfed out anyhow, it's more-or-less inevitable the replacement wouldn't run under Windows.
What you call "blacklisting" is something that would only upset Paris Hilton or one of the girls from The Hills? Please tell me I'm misunderstanding this.
Not if you're self-employed - it's not unusual for a lot of your work to come through networking and people talking to each other. That sort of thing is Extremely Bad in such cases.
Now, I'm no lawyer, but that sounds to me an awful lot like you can't simply say "We're running Linux on these 50 desktops, so we're not counting them.
Sounds to me like you can. What are they going to do, sue you for not having a license on a computer where you use none of their software? Yea, thats going to hold up REAL well.
Looks more like MS is pretending PC=Windows, and conveniently ignoring the fact that Linux desktop distros exist.
There's a couple of issues with that, which is why it doesn't tend to get tested in practise.
Certainly in the UK, there's very little legal protection to stop a business signing a contract that makes no sense and that contract being enforceable. Microsoft are offering a contract which says in essence "you license this for every PC, whether you use it or not" and there's a real risk it could stand up. AFAIK, the legal system doesn't really take much account of the fact that most businesses have precisely zero negotiation power with the likes of Microsoft.
Getting sued is a PITA, particularly if you're a business. It takes up a lot of time. You wind up having to spend a lot of money on lawyers, and a lot of staff time going to court. Time which could be better spent on doing things that earn money, rather than defending yourself in court. Most businesses are therefore very reluctant to do anything that puts them at risk of being sued in the first place - particularly if the organisation doing the suing has, compared to you, effectively unlimited resources.
FWIW, I would dearly love to see that particular clause tested in court. But I don't think that's going to happen for those reasons.
As their IT consultant it's my job to make sure I'm not doing things which could land them in trouble. Incredibly, most aren't aware that I can't just install this one purchased copy everywhere they like.:)
Wouldn't necessarily land just your client in trouble. Check your professional indemnity insurance, there's a good chance it explicitly excludes cases involving software piracy.
In which case, the immense likelihood is not that 42 people received $1,357 each. More likely only one or two people got any money.
The rest got nothing.
Suddenly, it doesn't look like such a great deal. Furthermore, I can see an obvious way this could go wrong for the whistleblower:
Give too little evidence, and it won't be worth pursuing. Give too much, and as soon as the BSA show what they intend to take to court, your former employer will settle out of court.
But I can tell you with absolute certainty that past a certain point, large companies don't keep track of individual licenses, they just buy bulk site licenses (not physical copies) and some IT staff ignore the license (much like everyone ignores license agreements) and are only aware of software that they can audit. This results devices like laptops not being accounted, and when staff are fired/quit they don't "return the license." So in some cases the IT staff actually are over-purchasing licenses for software just so they don't have to deal with the BSA.
I'll tell you why that is, because I was tasked with keeping my former employer up to snuff with their licensing.
It is virtually impossible to get everything perfect. You'd think it was simple - if it's a commercial piece of software, one license per user.
Nope.
Let's start with Windows. We'll assume that your company has been making do with fairly elderly PCs for some time, but has since come into money and is taking the opportunity to replace every PC with new hardware running Windows 7. And, in order to make management easier and guarantee every PC is running the same build, as soon as they arrive you're going to reimage the whole lot with your own image with most of the software you need preinstalled.
Not with OEM Windows licenses you're not. The only person who's allowed to roll out Windows using an imaging-based system and an OEM Windows license is the OEM, not the customer. You have to pay Microsoft for an enterprise Windows license. But that enterprise license is an upgrade-only license - it's not OK to call your OEM and say "Can we have these PCs without Windows, because we've already got a licenses?", you still need to buy PCs with Windows.
OK, your company has come into some money. But you still don't have an unlimited budget, and buying a site-wide enterprise license for Windows is really going to bite. Then you remember there was some talk of moving some people with very limited requirements over to Linux. "Ah!" you think. "This could be just the thing - we can reduce the number of Windows licenses we need and that way we'll come in within budget". Well, you think that until you read the terms of the Microsoft enterprise license. "For licensing purposes, count the total number of PCs you own, and the number of Macs on which you will run the software." Note it doesn't say "Number of PCs on which you will run the software". Now, I'm no lawyer, but that sounds to me an awful lot like you can't simply say "We're running Linux on these 50 desktops, so we're not counting them." I have no idea how well such an argument would stand up if you were in court, but I do know that in my country, most of the consumer-protection laws which would frown on asking a consumer to agree to such terms don't apply to agreements between businesses. And most companies are extremely reluctant to become the first test case.
Now that's just Windows. Office is just as awkward (license it for every PC on an annual basis, it costs about a third of the normal license cost - okay, you have to pay every year but it means you have to find a third of the money you'd otherwise have to find. Say "We don't need everyone to have Office, we'll omit licensing it for these users" and suddenly you don't qualify for the annual licensing. So unless you can omit licensing it for a significant number of people, it actually works out dearer). I haven't even started to discuss licensing for Adobe's commercial products, which are different again.
I take your point regarding the GUI. But without a GUI - or at the very least a standardised way of describing the configuration that is consistent across all your applications - you haven't really got an AD clone. You've just got a few scripts making judicious use of rsync.
Lets say that I had a Linux OpenLDAP Server with Heimdal Kerberos (I do.) and I wanted to make it such that whenever a specific user logged in, he/she/it saw a specific background, and had specific Mail settings, and had specific stuff setup for them, and I wanted this to follow them everywhere. There is no facility in KDE to do that. I cannot tell KDE: "This user has this background wallpaper, their FireFox home page is: www.egroupware.com Their start up sound is iora.wav, etc." I can set that up on a per machine basis, but I can't store that information in OpenLDAP so they can use regardless of what their machine is, because KDE doesn't know to retrieve that information.
Doesn't sound like a server task to me.
Quoting DarkOx in this comment (which is the very comment you replied to that triggered this discussion in the first place)
As soon as you start having laptops and desktops running all around the office you can't manage the settings the user is talking about anymore. Yes you can do it at deployment time. Sure you could write init scripts to go fetch and overwrite/update rc files and stuff but you'd have to do all of it yourself and it would be a security nightmare to try and get correct without putting a lot of resources into it.
GPOs make it really easy change all the CSRs home pages to the new customer service portal, and set all the sales reps wall paper to the latest product sheet instead of their embarrassing personal photos any time its needed. It also makes it possible to do things like yes your screen saver is going to turn on and the desktop will be locked after 15min, no exceptions. Sometimes that sort of thing gets required for PayCardIndustry rules and the like, and those things change every now and then.
If we're talking about replicating something as highly polished as group policy, a script that runs on login to pull in configuration files isn't the hard bit. The hard bit is providing a central, consistent GUI-fied means of tweaking all those configuration files that reduces the configuration to tick-boxes, eliminating the risk of a typo causing havoc when an application tries to read an invalid configuration and if you're lucky reverts to default. If you're unlucky, the application is broken.
Realistically, you'd probably store the actual configuration information in a database of some sort then use that database to write out config files accordingly. Which means that now you have something almost as complicated as Active Directory, except you can't go out and hire people who already know it - which will make any self-respecting IT manager very nervous indeed. And it'll require quite a bit of ongoing maintenance because every time an application upgrade requires updates to the configuration file, your system will need tweaking too.
You still need to roll a LOT of your own scripts - there's nothing built into any desktop environment to say "members of group A get this config file, members of group B get that config file".
There's also no easy way to state "This is the base configuration. In addition to this, apply these rules from group A and those rules for group B."
Sure, you could script all of this yourself - but when discussing Linux on the desktop, the question being asked is not "can you somehow persuade the system to get configuration for virtually everything from a single, central location and then tweak that configuration on a per-group basis?", it's "does the system support some efficient means of doing all that out of the box?".
As far as Linux goes, the answer to the first question is obviously "yes". But the answer to the second question is "no, it'll require a fair bit of work and most of that work will have to be done by someone who knows what they're doing rather than some cheap fresh-out-of-college Windows technician. And if you want that person to put things together in such a fashion that future configuration changes can be made by the cheap fresh-out-of-college Windows technician without having to train the Windows technician up to the level where they can demand substantially more money, the cost involved is going to wipe out any savings several times over".
This more-or-less eliminates Linux on the desktop in anything other than organisations where you can nail the desktop down for 60% of the staff so it doesn't require that level of detailed per-group configuration in the first place. Even then, you'd probably find Windows on the desktop of the other 40%.
A Nokia executive once said that switching to Android would be like peeing your pants for warmth. It might help temporarily, but would turn your phones into commodities. Nokia would be forced to sell based on price alone!
As opposed to selling them on the basis of the fantastic extra features that are unique to Nokia, one assumes?
WTF is the point in having a distribution complete with sophisticated package management if the first thing you're going to do is basically ignore the whole lot and use some totally different system because the distribution's own packages are unsuitable?
Slashdot Mirror
In the old days, using BCC in emails you sent was considered a "stab in the back" strategy. It was considered fine to use it for mass email sending but not for specific emails you send to a specific group of people. Using CC was the prescribed strategy to adopt.
Quite correct, hence why I've seen at least one employer ban it outright.
Didn't stop people CC'ing in the chain of command as a means of stabbing someone in the back, just meant that the stab-ee knew about it straight away.
replying to my own post, but...
the correct term is UNLAWFUL, not illegal.
Breaking a contract is civil law - IANAL but I'm pretty sure the correct term for that is civil law, not contract law.
Thing is, most jurisdictions do have criminal law regarding unauthorised access to computer systems. Facebook's terms are pretty clear that you're the only person authorised to log in under your name. In which case, you could probably argue that giving someone else your password is essentially aiding and abetting.
Arguably, it's not necessary to go that far. There's only a handful of tier one carriers, if you can force them to stop routing all traffic within the US, you may not shut down the Internet in the US entirely but you'd definitely cripple it.
Millions of people manage to use encrypted systems every day for Internet banking or shopping. Encryption does not have to be hard.
What is hard is providing a user interface to a means of encryption so that the complications are reduced or eliminated while still maintaining some semblance of security. AFAICT, nobody's managed to do that in a fashion suitable for anyone to use on arbitrary streams of data that need to be encrypted and passed around as part of a batch process.
The way Facebook is designed (and, for that matter, its popularity) means you can't. Or at least, probably shouldn't.
The main reason why is the photo sharing feature. On facebook or not, there's a good change that quite a few photos of you have been made public (yes, including that embarrassing one from last year when you had a bit too much to drink), tagged your name against it and it's there for all to see. There have been instances of people losing their jobs because of photos on facebook - well, you could (at least in theory) lose your job because of a photo of you someone else put up even though you've never used the damn site.
About the only thing you can do to try and prevent this is to sign up, make sure any photos of you are tagged and associated with your login then either remove those tags yourself or set your privacy settings so photos including you aren't public. Until the next time Facebook change their privacy defaults - which they'll do all they like because the users aren't the customers.
It's the electronic equivalent of graffiti on the bridge over the main road into town saying "kiwimate is a tosser!" except it comes with photographic evidence and it's much more likely to get distributed to anyone around the world than a bridge is.
Something like that, yes. I hadn't heard of Sparkle, but it looks like it's roughly the right idea.
The reason it needs to be in the OS is because if it isn't, there's precious little chance of third-party software supporting it. Not only would it reduce these risks, but it could hook into Active Directory for enterprises.
Though existing companies providing network management software would probably have something to say about that.
I've been saying this for some time: Windows (and to a lesser extent OS X) needs an API so updates are centralised, configured and installed from a single interface.
OS X has the app store. Linux distributions have repositories. Both of these solve this problem very neatly, and it's a lot easier to keep everything up to date. But I don't think centralised distribution is necessary - just an API call so you can say to the operating system "this is the name of the application, this is an RSS feed where updates are published, this is the key with which updates will be signed, this is how frequently you should check for updates" would probably solve most of the problems.
The mess we have right now is the reason why there is always something on a PC that needs updating.
anything which can be explained by stupidity. Or, for that matter, planning.
I suspect it's rather simpler than "Micro$oft hates GPL!!11oneone", and has nothing to do with any particular hatred of the GPL and related licenses.
Let's say, for the sake of argument, you're building an apps store in the style of Apple. It's going to look all pretty, it's going be dead simple to download anything, people can submit apps, they go through an approval process, they go on the store. Installing is a matter of "click once", and that's about the only thing you're going to make visible to the end user.
You anticipate having thousands of apps sooner rather than later, so the complicated part isn't going to be the website. It's going to be putting together the business logic and processes that drive it.
The problem with something like the GPL is that all of a sudden, your process for accepting for approval, approval itself and distributing software suddenly becomes a hell of a lot more complicated because you now need to keep track of whether or not an application requires the source code to be made available. Remember the GPL applies to anyone distributing the software, so you can't just palm this back to the developer. You now need a separate interface to your apps store from the developer site which allows downloading source code where available, you need to keep track of which apps have which licenses - and you need to track which licenses specifically state "You must distribute source code".
Unless you took this into account when you designed the apps store and the processes behind it (which is likely if you're Google, but vanishingly unlikely if you're Microsoft), you now have a problem. Your entire process is set up on the assumption that you are under no obligation to distribute the source code for apps, this throws a spanner in the works. What is the cheapest, quickest, easiest solution?
1. Ban licenses which demand you distribute source code such as the GPL.
2. Go back and rewrite all your processes to account for licensing issues. Any software developed around those processes will also need changing.
TL;DR : More likely that Microsoft don't care enough about F/OSS to bother accounting for it in their processes for their app store.
Languages change over time. If you want proof, go read The Canterbury Tales.
If, OTOH, you want a language which hasn't changed over time, I suggest you learn Latin and communicate in nothing else for the rest of your life.
Well, with Tivo you didn't buy their EPG. You bought the box but in order for it to be any use you subscribed to the EPG. Which might mean they'd get away with it - were it not for the fact that they offered one-off lifetime subscriptions for £120.
Having said all that, they're a business. And almost all business decisions can be boiled down to money.
Were I in Tivo's shoes, I'd have worked the arithmetic something like this:
Worst case scenario: Customer(s) take us to court, win, we're obliged to refund some proportion of their lifetime subscription. This isn't the US where you can sue for the loss at £120 then the "hurt feelings" at £1,000,000.
The only customers who are likely to make a fuss are those still using a lifetime subscription.
So, how many people with lifetime subscriptions are still using them? Should be easy enough to figure out, the boxes phone home every night to download their EPG. Which means there must be some means of authenticating the box or how else would you know that it was associated with a lifetime sub? Once you've worked out this number, let's call it N
Multiply N by the cost of the subscription (£120) and you've got an idea of the worst-case you'd be paying out - excluding legal fees. I would be astonished if that number is much more than, say, £120,000 - Tivo pulled out of the UK years ago, the only boxes which are affected are going to be getting on a bit now.
Okay, so how much does it cost to maintain the EPG service - including a pool of dialin modems, the servers and the software? This would be a service which every other PVR in the country is getting straight from Freeview/Cable/Satellite system and so the cost of running it is exclusive to your old product. I bet you anything you like it's expensive enough that even with the worst-case payout, it's still cheaper within three years to cancel the service.
If it's in an index-linked fund there's a good chance you'll wind up beating automated traders. 80% of the things that try to beat the market average fail, sometimes spectacularly.
Doubt it. It's not like you're going to cobble together the systems running a stock exchange from whatever you could find leftover in the warehouse.
Infinitely more likely that there's only a handful of software development houses with the expertise to develop stock exchange systems of this sort of size. (Which makes sense, as there's only a handful of big stock exchanges). Which means there's only a handful of companies that are going to be taken seriously if they bid for the contract.
Assuming there's only, say, three such development companies, only one of them provides a product that runs under Windows and that one's being turfed out anyhow, it's more-or-less inevitable the replacement wouldn't run under Windows.
What you call "blacklisting" is something that would only upset Paris Hilton or one of the girls from The Hills? Please tell me I'm misunderstanding this.
Not if you're self-employed - it's not unusual for a lot of your work to come through networking and people talking to each other. That sort of thing is Extremely Bad in such cases.
Now, I'm no lawyer, but that sounds to me an awful lot like you can't simply say "We're running Linux on these 50 desktops, so we're not counting them.
Sounds to me like you can. What are they going to do, sue you for not having a license on a computer where you use none of their software? Yea, thats going to hold up REAL well.
Looks more like MS is pretending PC=Windows, and conveniently ignoring the fact that Linux desktop distros exist.
There's a couple of issues with that, which is why it doesn't tend to get tested in practise.
FWIW, I would dearly love to see that particular clause tested in court. But I don't think that's going to happen for those reasons.
As their IT consultant it's my job to make sure I'm not doing things which could land them in trouble. Incredibly, most aren't aware that I can't just install this one purchased copy everywhere they like. :)
Wouldn't necessarily land just your client in trouble. Check your professional indemnity insurance, there's a good chance it explicitly excludes cases involving software piracy.
In which case, the immense likelihood is not that 42 people received $1,357 each. More likely only one or two people got any money.
The rest got nothing.
Suddenly, it doesn't look like such a great deal. Furthermore, I can see an obvious way this could go wrong for the whistleblower:
Give too little evidence, and it won't be worth pursuing. Give too much, and as soon as the BSA show what they intend to take to court, your former employer will settle out of court.
But I can tell you with absolute certainty that past a certain point, large companies don't keep track of individual licenses, they just buy bulk site licenses (not physical copies) and some IT staff ignore the license (much like everyone ignores license agreements) and are only aware of software that they can audit. This results devices like laptops not being accounted, and when staff are fired/quit they don't "return the license." So in some cases the IT staff actually are over-purchasing licenses for software just so they don't have to deal with the BSA.
I'll tell you why that is, because I was tasked with keeping my former employer up to snuff with their licensing.
It is virtually impossible to get everything perfect. You'd think it was simple - if it's a commercial piece of software, one license per user.
Nope.
Let's start with Windows. We'll assume that your company has been making do with fairly elderly PCs for some time, but has since come into money and is taking the opportunity to replace every PC with new hardware running Windows 7. And, in order to make management easier and guarantee every PC is running the same build, as soon as they arrive you're going to reimage the whole lot with your own image with most of the software you need preinstalled.
Not with OEM Windows licenses you're not. The only person who's allowed to roll out Windows using an imaging-based system and an OEM Windows license is the OEM, not the customer. You have to pay Microsoft for an enterprise Windows license. But that enterprise license is an upgrade-only license - it's not OK to call your OEM and say "Can we have these PCs without Windows, because we've already got a licenses?", you still need to buy PCs with Windows.
OK, your company has come into some money. But you still don't have an unlimited budget, and buying a site-wide enterprise license for Windows is really going to bite. Then you remember there was some talk of moving some people with very limited requirements over to Linux. "Ah!" you think. "This could be just the thing - we can reduce the number of Windows licenses we need and that way we'll come in within budget". Well, you think that until you read the terms of the Microsoft enterprise license. "For licensing purposes, count the total number of PCs you own, and the number of Macs on which you will run the software." Note it doesn't say "Number of PCs on which you will run the software". Now, I'm no lawyer, but that sounds to me an awful lot like you can't simply say "We're running Linux on these 50 desktops, so we're not counting them." I have no idea how well such an argument would stand up if you were in court, but I do know that in my country, most of the consumer-protection laws which would frown on asking a consumer to agree to such terms don't apply to agreements between businesses. And most companies are extremely reluctant to become the first test case.
Now that's just Windows. Office is just as awkward (license it for every PC on an annual basis, it costs about a third of the normal license cost - okay, you have to pay every year but it means you have to find a third of the money you'd otherwise have to find. Say "We don't need everyone to have Office, we'll omit licensing it for these users" and suddenly you don't qualify for the annual licensing. So unless you can omit licensing it for a significant number of people, it actually works out dearer). I haven't even started to discuss licensing for Adobe's commercial products, which are different again.
I take your point regarding the GUI. But without a GUI - or at the very least a standardised way of describing the configuration that is consistent across all your applications - you haven't really got an AD clone. You've just got a few scripts making judicious use of rsync.
News to me.
Quoting Zombie Ryushu in this comment:
Lets say that I had a Linux OpenLDAP Server with Heimdal Kerberos (I do.) and I wanted to make it such that whenever a specific user logged in, he/she/it saw a specific background, and had specific Mail settings, and had specific stuff setup for them, and I wanted this to follow them everywhere. There is no facility in KDE to do that. I cannot tell KDE: "This user has this background wallpaper, their FireFox home page is: www.egroupware.com Their start up sound is iora.wav, etc." I can set that up on a per machine basis, but I can't store that information in OpenLDAP so they can use regardless of what their machine is, because KDE doesn't know to retrieve that information.
Doesn't sound like a server task to me.
Quoting DarkOx in this comment (which is the very comment you replied to that triggered this discussion in the first place)
As soon as you start having laptops and desktops running all around the office you can't manage the settings the user is talking about anymore. Yes you can do it at deployment time. Sure you could write init scripts to go fetch and overwrite/update rc files and stuff but you'd have to do all of it yourself and it would be a security nightmare to try and get correct without putting a lot of resources into it.
GPOs make it really easy change all the CSRs home pages to the new customer service portal, and set all the sales reps wall paper to the latest product sheet instead of their embarrassing personal photos any time its needed. It also makes it possible to do things like yes your screen saver is going to turn on and the desktop will be locked after 15min, no exceptions. Sometimes that sort of thing gets required for PayCardIndustry rules and the like, and those things change every now and then.
How is that discussing server admin?
If we're talking about replicating something as highly polished as group policy, a script that runs on login to pull in configuration files isn't the hard bit. The hard bit is providing a central, consistent GUI-fied means of tweaking all those configuration files that reduces the configuration to tick-boxes, eliminating the risk of a typo causing havoc when an application tries to read an invalid configuration and if you're lucky reverts to default. If you're unlucky, the application is broken.
Realistically, you'd probably store the actual configuration information in a database of some sort then use that database to write out config files accordingly. Which means that now you have something almost as complicated as Active Directory, except you can't go out and hire people who already know it - which will make any self-respecting IT manager very nervous indeed. And it'll require quite a bit of ongoing maintenance because every time an application upgrade requires updates to the configuration file, your system will need tweaking too.
You still need to roll a LOT of your own scripts - there's nothing built into any desktop environment to say "members of group A get this config file, members of group B get that config file".
There's also no easy way to state "This is the base configuration. In addition to this, apply these rules from group A and those rules for group B."
Sure, you could script all of this yourself - but when discussing Linux on the desktop, the question being asked is not "can you somehow persuade the system to get configuration for virtually everything from a single, central location and then tweak that configuration on a per-group basis?", it's "does the system support some efficient means of doing all that out of the box?".
As far as Linux goes, the answer to the first question is obviously "yes". But the answer to the second question is "no, it'll require a fair bit of work and most of that work will have to be done by someone who knows what they're doing rather than some cheap fresh-out-of-college Windows technician. And if you want that person to put things together in such a fashion that future configuration changes can be made by the cheap fresh-out-of-college Windows technician without having to train the Windows technician up to the level where they can demand substantially more money, the cost involved is going to wipe out any savings several times over".
This more-or-less eliminates Linux on the desktop in anything other than organisations where you can nail the desktop down for 60% of the staff so it doesn't require that level of detailed per-group configuration in the first place. Even then, you'd probably find Windows on the desktop of the other 40%.
A Nokia executive once said that switching to Android would be like peeing your pants for warmth. It might help temporarily, but would turn your phones into commodities. Nokia would be forced to sell based on price alone!
As opposed to selling them on the basis of the fantastic extra features that are unique to Nokia, one assumes?
Oh dear.
That's what the FSM invented debian-backports for.
WTF is the point in having a distribution complete with sophisticated package management if the first thing you're going to do is basically ignore the whole lot and use some totally different system because the distribution's own packages are unsuitable?