US is not unique. The same used to be valid here in the UK for work permits. In fact I nearly went through this process myself. The only reason I did not have to was that there is a list of skills for which the newspaper ads can be shortcut and my skills happened to be on the particular edition of the list valid at that particular time.
This is business as usual all over the world. By the time it gets to this stage the person has worked for the company for at least several years, is known to be what the company needs and the company actually is doing this as a loyalty measure on top of his package. It has already failed to hire someone local to do the job for years and is most likely paying the person in question an above market package. The green card/work permit extension/etc is just another loyalty perk.
Bananas are way more labour intensive, have much higher margin and much easier to automate. The most labour intensive part of growing bananas is the pinching, where a person has to go around and cut of the flowers off after they have opened, but before they have been pollinated (or something like that). That is trivial to automate. It does not even require proper colour recognition or complex spatial navigation around a tree. All you need to do is recognise the flower shape on the growing banana cluster. Which is also conveniently one per plant.
I have used a similar approach to picking for a completely different crop 20+ years ago. We picked carrots that way. One-two people go and pull and pile in the middle of the row, doing nothing else. Two more people sort leaving them on the ground and two-three pack the sorted crop. The efficiency was around 6 times higher than the standard picking by hand where a single person picks them, sorts them and carries the lot the collection point for packing. In fact the efficiency was so high that we ended up having a serious pay dispute regarding pay and bonuses.
So a robot which determines an optimal sequence for an entire tree and picks out of it may as well outpick a human team. Though, oranges will probably be the wrong crop to try this first. They are not that labour intensive. The income per square mile and margins are also not that great. Though the most labour intensive crops like bananas do not grow in places like California which can afford a pilot robot deployment.
Anyway, it will be interesting to see how this goes in 3-4 years from now
Absolutely. Many examples of that. This was the case in the UK before the new countries joined the EU. The ones who shouted loudest against that were the politicos representing places using illegal immigrant slave labour. Now they have to pay them legally, pay the minimum wage, pay NI and taxes. That does hurt the bottom line ya know.
After that just make a fake package that depends on all of them and includes the relevant customisation. Not very difficult. It has one disadvantage - it does not make the install fully automatic. You have to answer questions which may lead to inconsistency.
Unfortunately, debian still does not read everything in every package out of the debconf database so even prepopulating it will not always help. So unless you are doing 50+ it is cheaper to make a custom package, but still hire someone to press enter and type in Y/N where necessary.
Underscore is not an allowed character in DNS and used to be commonly used in some of the more primitive phishing setups a while ago. So not surprising it is being filtered. In fact it should.
You are painting a very entertaining rosy picture as far as the UK is concerned.
So let's see one day when I actually need a mobile access and the reality of mobile data in the UK not through pink mobile operator marketing glasses. So let's see shall we?
1. Get up, sync the laptop, leave the house - so far nothing mobile, do not need it. 2. Get on the train to Cambridge to London train. Try to connect to the net. Available GPRS timeslots at the Camrbidge railway station - around 2 (Vodafone and O2 are roughly the same here). Available capacity before 9am - 0bytes per second. The cretinous f***heads at the operator end QoS up the Blackberry traffic so if you have a train full of business people the capacity for the other data users is 0. Slightly better after 9, but still abissmall. 3G is a tad bit better, but this is temporary due to the low penetration of the 3G BB. 3. Train Cambridge to London - no 3G coverage half of the time, GPRS coverage around 1 timeslot when available. 6+ tunnels most of them long enough to cause a VPN timeout and cause a reconnect (3G is slightly better due to soft handover here, but it is not available). Overall - just about usefull to reply a couple of emails. Browse? You gotta be kidding. In the morning - totally impossible due to BB eating all capacity. After that - about as bad as browsing on a 14400 modem. 4. London - tube. No coverage. Whatsoever. The sole reason that our best beloved Mayor is a greedy c***. London tube refuses to put DAS or picocells because they want to give it exlcusively to a single operator and shave the profits. There is a ruling by the competition comission that this is not acceptable so the tube simply does not put any access in. Result - no access. 3G or no 3G. 5. Arrive wherver - no need for 3G or GPRS as there is network and/or wireless.
So overall - out of the 4h a day when I needed GPRS/3G coverage I got on the average around 10Kbit per second and it was unavailable half of the time. That is not service you can rely on. That is sh*te.
Agree. But in this case the number of clients supported and optimisation is likely to be a much bigger problem. I have seen quite a few disastrous WiFi deployments in areas which have high client density. Throwing more bandwidth at it will not do anything to solve this class of problems. For these you need better (smarter) infrastructure with more APs and a wireless switch behind them to tweak the power settings and nudge clients between APs by making them think that the power on a neigbouring AP is better.
Well... Dunno about you, but after a good night of nethacking I sometimes long for a couple of spells. A stinking cloud could have done wonders to one of those commuter trains.
I had the same experience with HP a couple of years back when it decided to offer PCs with Mandrake. They were not available through the business channel and that was it.
Houston seems like a better option. And the only one to shake some sense into the current White House crowd. There is no better reality check than seeing your own home levelled to ground. Pity for all the collateral damage though.
It is a matter of changing its status. Electricity and phone in remote areas around the world are available because the utility companies operate under an universal service obligation. They have to provide these services to X% of the population where X is usually in the 99+. Broadband is not subject to universal service obligation. It is considered in some places, but so far I do not think that it has made it to the list of things utilities must provide regardless of the location.
Nildram pulled this one on me in the UK 20 days ago. The only thing is that they were also rash enough to claim that they are doing it to "help VOIP and other business applications". Guess what the QoS on all of my non-Nildram VOIP links went to hell straight away. And as you rightly pointed - I am not paying. Any more. Got my service migrated to someone else.
As someone who has done QoS for a living for 10 years at all levels from a SOHO to an international Telco I can say that the problem is not with implementing QoS, the problem is with implementing it badly.
There are ways to roll QoS out in a manner that will keep all users happy using either internal software development or by buying off the shelf software (there are at lest 2 companies in this space which have a long list of successful telco deployments). Unfortunately deploying it this way requires competence and understanding of how to productize QoS and bill for it. This is something which the current generation of network engineers and product managers in most telcos have very little clue about (with very few exemtptions).
That is an interesting and rather entertaining interpretation of the Freedom of Information Act.
Anyway problem elsewhere. BBC already tried to release un-DRM-ed content and got into hot water for it. More specifically they released all Bethoven Symphonies as played on BBC radio via their web site 2 or 3 years ago (I got 6-9 and missed the first 5). And they stopped. Guess why - because the rest of the music industry threatened to sue them for undercutting classical music prices.
Personally, I found the argument extremely entertaining. The quality of the recording was not anywhere near what a classical audiophile will consider worth having (considerably worse than a good FM radio broadcast) and the quality of the execution by the orcherstra (and chorus) was a total joke. One can buy a Slovak Philharmonic orchestra "present for the aunt" CD from one of those 10 quid for 20 CDs bundles with much better quality and execution. I am not even talking about going to a music store and buying a proper recording with someone like H. Karayan as a conductor. And even so, the industry went up in arms like one and the Beeb backed down.
Not necessarily. Some fixes can definitely meet the non-obviousness criteria. And looking for vulnerabilities which require non-obvious fixes and patenting them is a viable business model as well.
In fact, there is a well known precedent, when the icmp-tcp interaction and various windowing flaws in tcp implementations were discovered around 2001(IIRC) the fixes were brainstormed at IETF and a list of suggested fixes came out. And surprise, surprise it appeared that Cisco who had the worst list of flaws and was actively participating in devising workarounds for them was quietly trying to patent some of the fixes. IIRC, they backed down on that one due to for violation of disclosure requirements as well as severe industry pressure. What happened to them at the time does not apply to patent trolls. I do not quite see a troll backing down so easily.
He probably meant customs, not immigration and here is some supporting evidence in the form of a quote from an interview with Ewan Mcgregor (I have heard a few other actors sharing similar experiences on other talk shows):
Kirsty : Did you come to people's attention after you did rainspotting?
Ewan : In the states, yeah, that changed things yeah.
Kirsty : Still look back on that and think it was a great performance?
Ewan : It was fantastic, I was quite pleased with myself in it , yeah. Best shoot, smoothest experience, best actors, best crew it was fantastic. Around that time at Chicago airport going to do ER, US customs asked what I was doing and I explained that he might have seen me in Trainspotting, sent over to Red immigration zone and stripped off. 'But I'm an actor for christs sake!, I'm not really a heroin addict!'
Yep, Ewan go and tell that to US customs. Same for "I am not really bringing that phone for resale".
Disclaimer: I used to work in the field (not for qualcom) and I am extremely happy no longer to.
Anyone working in the field is well aware of the phenomenon known as "visit from Qualcomm" legal department. In fact, it is a most common question asked when discussing a financial plan or investment in a wireless related SMB: "And have you had a visit from Qualcom yet?".
It is essentially the same tactic as used by IBM in the early 90-es with their PC-based patents. You are left to develop something, start a business and hopla two chaps in black suits show up with a list of patents which you have supposedly infringed. GTE, Nokia, Motorola, Broadcom were simply big enough to tell these chaps to f*** off, and fight it out. Frankly, I can bet that every single one of them fired the legal salvo after a visit from Pan Legalicus Qualcommi. In fact, in Nokia's case it is known to be so as it has happened as a result of Qualcom violating its obligations to license standardised intellectual property on non-discriminatory terms.
Exactly, and if you trace the thread to the original GP you will see that someone was having a belly laugh at "linux sysadmin" who could not make linux his primary desktop. And my comment was that I am not surprised in the slightest. I interviewed people for 5+ years for job(s) that involved this and I did not meet a single person who had all the necessary knowledge. Some individuals had some bits, but none had all.
Essentially corporate unix workstation management is a lost art and the lack of people knowledgeable in it is exactly this that is hindering linux adoption as a desktop in the workplace. The current flock of sysadmins know how to run Unix/linux servers and windows servers and workstations. They do not know how to run an efficient Linux desktop installation. At best, they try to simulate windows workstation like approaches by using massive software/client management packages which is costly and inefficient (unix had it solved long ago, no point to reinvent the wheel). At worst they try to manage the lot on a per-machine basis using mad scripting and rsync abuse which is even worse.
If you go out on the job market trying to hire a person for Unix workstation management that is capable of designing and running a 50+ seat shop in a cost efficient manner (which requires the list of skills described in my original GP) you will be tearing your hair out.
So it is not Linux that failed. It is the sysadmin profession. All the tools are there. Though some "corporate" oriented distributions repeatedly ship branded garbageware without testing them (at least used to). It is that the people have no idea how to use these tools.
Zenworks as far as this is a solution looking for a problem. Unix has had it solved more than 15 years ago via automounting. Any changes since have been mostly cosmetic.
As far as the complexity of the infrastructure is concerned a fully centralised infrastructure made of identical clients controlled in a single place in the center is inherently less complex to manage compared to having the settings in the clients and pushing them via a management package.
As far as storage management it is all alive and well at the server side, but it does not work out neither technically, nor financially for workstations. Once again unix has had it sorted out long ago. While we may hate NFS and AFS they do the job nicely.
And as far as sysadmins are concerned, I will repeat my statement - 95%+ of the sysadmins in the UK do not know how to run an end-user workstation installation in a corporate environment. Their knowledge and background is limited to a modern server shop where the users do not have accounts. This knowledge does not apply well to corporate workstation space.
I guess the replies in this thread prove in detail my statement about the current flock of "linux sysadmins".
Here is the detailed explanation to (1)
NIS and LDAP can both be used to ship autofs maps and the relevant databases which make out a successfull corporate deployment. Both have their limitations and while it is possible to make out a deployment with only one of them a successful big rollout needs both.
Currently only NIS can be used to limit NFS access to a specific directory to a specific machine in a centralised manner via netgroups. Unfortunately, NIS has a number of nasty problems when operating on lone machines at the end of vpn tunnels, offline, etc as well as for large scale replication. There LDAP is clearly a better solution, but it cannot provide netgroups to nss and it is also quite slow.
In order to create a scalable and maintainable large corporate deployment, $HOME (and other common shares) should be centralised on NFS (or other network FS) and accessed via an autofs mount controlled using NIS or LDAP. If implemented correctly any user can stand up, move to a different workstation sit down and start working straight away (provided that netgroup permissions allow this). All machines can be absolutely identical with no local personalisation whatsoever (even in a developer shop). Further to this, permissions, backup, maintenance are fully centralised and can scale easily into the thousands of workstations with no extra workload. Further to actual $HOMEs and shares can be migrated back and forth across the network with minimal disruption. And so on, and so forth...
In the days of SunOS and large university Unix networks any selfrespecting sysadmin knew how to do this (with Sun's automounter). Nowdays less than 5% of people claiming to be "experienced linux sysadmins" have an idea on how to do this. And that is even without going into arcane stuff like executable automounter maps and other ways to do things that are generally considered outright impossible.
There are also plenty of people who claim to be linux sysadmins or even worse - have multiple years of work experience and have no clue whatsof***ever on how to use Linux in a desktop environment. Based on interviewing people for years (in all salary brackets starting from PFY all the way to seasoned BOFHs), I have noted that in the UK the following applies to "linux sysadmins" (quotes intended):
1. Less than 5% know and understand autofs/nis|ldap/netgroups which are essential to run Linux as a corporate desktop. In fact, I have met more non-sysadmin people who do something else for a living, than "professional linux sysadmins" that know how to do this. 2. Less than 10% can read a bootlog A-Z and explain all entries. 3. Less than 10% know how to configure X. 4. Less than 5% can spec a low end system for purchasing as a dedicated desktop for Linux including checking manufacturer specs vs non-RedHat distribution requirements.
As a result it is no wonder that "a professional Linux sysadmin" cannot run Linux as a desktop. Somehow I am not surprised in the slightest.
Not quite so. Depends on the actual hell location.
If congestion hell is located on the access gear you should expect it to have the three heads of Cerberus - the loss head, the jitter head and the delay head. The reason is that the queues there are deep enough for all of these to occur.
If the hell is distributed across the backbone and the peering points drop is going to be the most likely result (the queue transmission times are not long enough to make a real influence on the other).
By the way, the really nasty hell is the access hell, not the backbone hell. Most backbones are not currently congested enough to make the backbone hell hurt so much. It will take changing capacity planning models, evaluating the new ones for stability and deploying the new models that take advantage of QoS to change this. That is not an easy task even if this is done from the top via an executive order.
Now, access (and to lesser extent peerings) is a completely different matter. There even minor QoS knob tweaking will have a major impact.
Yep, been there, seen that. I have seen SEL on fedora (4) in permissive mode still breaking an app and had it fixed by turning the damn thing off (it did work properly on Debian 4.0 though). The app was using tty functions from a web-server CGI context which is a requirement for working expect scripts.
As far as your comment on error codes and 'Permission denied by MAC policy', quite a few (if not most) of app developers do not handle all possible error codes returned by the OS and do not have a "catch-all" clause when handling errors. So returning a "new and wonderfull" error code is actually likely to cause more mayhem, than returning one of the "well known" error codes like -EACCES. I would rather have the actual error code configurable on a per-item basis (dunno if SEL can do that as I have not yet committed to the several days necessary to learn its deep internals).
The question is: Why compare total R&D, Manufacturing and Operations budget to a lone manufacturing cost without any of the R&D and operation costs taken into account? And the answer is - because it sounds cool on Slashdot.
Slashdot Mirror
US is not unique. The same used to be valid here in the UK for work permits. In fact I nearly went through this process myself. The only reason I did not have to was that there is a list of skills for which the newspaper ads can be shortcut and my skills happened to be on the particular edition of the list valid at that particular time.
This is business as usual all over the world. By the time it gets to this stage the person has worked for the company for at least several years, is known to be what the company needs and the company actually is doing this as a loyalty measure on top of his package. It has already failed to hire someone local to do the job for years and is most likely paying the person in question an above market package. The green card/work permit extension/etc is just another loyalty perk.
Nothing to see here, move along.
One example off the top of my head:
Bananas are way more labour intensive, have much higher margin and much easier to automate. The most labour intensive part of growing bananas is the pinching, where a person has to go around and cut of the flowers off after they have opened, but before they have been pollinated (or something like that). That is trivial to automate. It does not even require proper colour recognition or complex spatial navigation around a tree. All you need to do is recognise the flower shape on the growing banana cluster. Which is also conveniently one per plant.
Not so sure.
I have used a similar approach to picking for a completely different crop 20+ years ago. We picked carrots that way. One-two people go and pull and pile in the middle of the row, doing nothing else. Two more people sort leaving them on the ground and two-three pack the sorted crop. The efficiency was around 6 times higher than the standard picking by hand where a single person picks them, sorts them and carries the lot the collection point for packing. In fact the efficiency was so high that we ended up having a serious pay dispute regarding pay and bonuses.
So a robot which determines an optimal sequence for an entire tree and picks out of it may as well outpick a human team. Though, oranges will probably be the wrong crop to try this first. They are not that labour intensive. The income per square mile and margins are also not that great. Though the most labour intensive crops like bananas do not grow in places like California which can afford a pilot robot deployment.
Anyway, it will be interesting to see how this goes in 3-4 years from now
Absolutely. Many examples of that. This was the case in the UK before the new countries joined the EU. The ones who shouted loudest against that were the politicos representing places using illegal immigrant slave labour. Now they have to pay them legally, pay the minimum wage, pay NI and taxes. That does hurt the bottom line ya know.
After that just make a fake package that depends on all of them and includes the relevant customisation. Not very difficult. It has one disadvantage - it does not make the install fully automatic. You have to answer questions which may lead to inconsistency.
Unfortunately, debian still does not read everything in every package out of the debconf database so even prepopulating it will not always help. So unless you are doing 50+ it is cheaper to make a custom package, but still hire someone to press enter and type in Y/N where necessary.
Underscore is not an allowed character in DNS and used to be commonly used in some of the more primitive phishing setups a while ago. So not surprising it is being filtered. In fact it should.
You are painting a very entertaining rosy picture as far as the UK is concerned.
So let's see one day when I actually need a mobile access and the reality of mobile data in the UK not through pink mobile operator marketing glasses. So let's see shall we?
1. Get up, sync the laptop, leave the house - so far nothing mobile, do not need it.
2. Get on the train to Cambridge to London train. Try to connect to the net. Available GPRS timeslots at the Camrbidge railway station - around 2 (Vodafone and O2 are roughly the same here). Available capacity before 9am - 0bytes per second. The cretinous f***heads at the operator end QoS up the Blackberry traffic so if you have a train full of business people the capacity for the other data users is 0. Slightly better after 9, but still abissmall. 3G is a tad bit better, but this is temporary due to the low penetration of the 3G BB.
3. Train Cambridge to London - no 3G coverage half of the time, GPRS coverage around 1 timeslot when available. 6+ tunnels most of them long enough to cause a VPN timeout and cause a reconnect (3G is slightly better due to soft handover here, but it is not available). Overall - just about usefull to reply a couple of emails. Browse? You gotta be kidding. In the morning - totally impossible due to BB eating all capacity. After that - about as bad as browsing on a 14400 modem.
4. London - tube. No coverage. Whatsoever. The sole reason that our best beloved Mayor is a greedy c***. London tube refuses to put DAS or picocells because they want to give it exlcusively to a single operator and shave the profits. There is a ruling by the competition comission that this is not acceptable so the tube simply does not put any access in. Result - no access. 3G or no 3G.
5. Arrive wherver - no need for 3G or GPRS as there is network and/or wireless.
So overall - out of the 4h a day when I needed GPRS/3G coverage I got on the average around 10Kbit per second and it was unavailable half of the time. That is not service you can rely on. That is sh*te.
Agree. But in this case the number of clients supported and optimisation is likely to be a much bigger problem. I have seen quite a few disastrous WiFi deployments in areas which have high client density. Throwing more bandwidth at it will not do anything to solve this class of problems. For these you need better (smarter) infrastructure with more APs and a wireless switch behind them to tweak the power settings and nudge clients between APs by making them think that the power on a neigbouring AP is better.
Well... Dunno about you, but after a good night of nethacking I sometimes long for a couple of spells. A stinking cloud could have done wonders to one of those commuter trains.
I had the same experience with HP a couple of years back when it decided to offer PCs with Mandrake. They were not available through the business channel and that was it.
Houston seems like a better option. And the only one to shake some sense into the current White House crowd. There is no better reality check than seeing your own home levelled to ground. Pity for all the collateral damage though.
It is a matter of changing its status. Electricity and phone in remote areas around the world are available because the utility companies operate under an universal service obligation. They have to provide these services to X% of the population where X is usually in the 99+. Broadband is not subject to universal service obligation. It is considered in some places, but so far I do not think that it has made it to the list of things utilities must provide regardless of the location.
Absolutely.
Nildram pulled this one on me in the UK 20 days ago. The only thing is that they were also rash enough to claim that they are doing it to "help VOIP and other business applications". Guess what the QoS on all of my non-Nildram VOIP links went to hell straight away. And as you rightly pointed - I am not paying. Any more. Got my service migrated to someone else.
As someone who has done QoS for a living for 10 years at all levels from a SOHO to an international Telco I can say that the problem is not with implementing QoS, the problem is with implementing it badly.
There are ways to roll QoS out in a manner that will keep all users happy using either internal software development or by buying off the shelf software (there are at lest 2 companies in this space which have a long list of successful telco deployments). Unfortunately deploying it this way requires competence and understanding of how to productize QoS and bill for it. This is something which the current generation of network engineers and product managers in most telcos have very little clue about (with very few exemtptions).
That is an interesting and rather entertaining interpretation of the Freedom of Information Act.
Anyway problem elsewhere. BBC already tried to release un-DRM-ed content and got into hot water for it. More specifically they released all Bethoven Symphonies as played on BBC radio via their web site 2 or 3 years ago (I got 6-9 and missed the first 5). And they stopped. Guess why - because the rest of the music industry threatened to sue them for undercutting classical music prices.
Personally, I found the argument extremely entertaining. The quality of the recording was not anywhere near what a classical audiophile will consider worth having (considerably worse than a good FM radio broadcast) and the quality of the execution by the orcherstra (and chorus) was a total joke. One can buy a Slovak Philharmonic orchestra "present for the aunt" CD from one of those 10 quid for 20 CDs bundles with much better quality and execution. I am not even talking about going to a music store and buying a proper recording with someone like H. Karayan as a conductor. And even so, the industry went up in arms like one and the Beeb backed down.
Not necessarily. Some fixes can definitely meet the non-obviousness criteria. And looking for vulnerabilities which require non-obvious fixes and patenting them is a viable business model as well.
In fact, there is a well known precedent, when the icmp-tcp interaction and various windowing flaws in tcp implementations were discovered around 2001(IIRC) the fixes were brainstormed at IETF and a list of suggested fixes came out. And surprise, surprise it appeared that Cisco who had the worst list of flaws and was actively participating in devising workarounds for them was quietly trying to patent some of the fixes. IIRC, they backed down on that one due to for violation of disclosure requirements as well as severe industry pressure. What happened to them at the time does not apply to patent trolls. I do not quite see a troll backing down so easily.
Yep, Ewan go and tell that to US customs. Same for "I am not really bringing that phone for resale".
Disclaimer: I used to work in the field (not for qualcom) and I am extremely happy no longer to.
Anyone working in the field is well aware of the phenomenon known as "visit from Qualcomm" legal department. In fact, it is a most common question asked when discussing a financial plan or investment in a wireless related SMB: "And have you had a visit from Qualcom yet?".
It is essentially the same tactic as used by IBM in the early 90-es with their PC-based patents. You are left to develop something, start a business and hopla two chaps in black suits show up with a list of patents which you have supposedly infringed. GTE, Nokia, Motorola, Broadcom were simply big enough to tell these chaps to f*** off, and fight it out. Frankly, I can bet that every single one of them fired the legal salvo after a visit from Pan Legalicus Qualcommi. In fact, in Nokia's case it is known to be so as it has happened as a result of Qualcom violating its obligations to license standardised intellectual property on non-discriminatory terms.
Solar sail will be one of them. Various forms of nuclear drive - another.
Exactly, and if you trace the thread to the original GP you will see that someone was having a belly laugh at "linux sysadmin" who could not make linux his primary desktop. And my comment was that I am not surprised in the slightest. I interviewed people for 5+ years for job(s) that involved this and I did not meet a single person who had all the necessary knowledge. Some individuals had some bits, but none had all.
Essentially corporate unix workstation management is a lost art and the lack of people knowledgeable in it is exactly this that is hindering linux adoption as a desktop in the workplace. The current flock of sysadmins know how to run Unix/linux servers and windows servers and workstations. They do not know how to run an efficient Linux desktop installation. At best, they try to simulate windows workstation like approaches by using massive software/client management packages which is costly and inefficient (unix had it solved long ago, no point to reinvent the wheel). At worst they try to manage the lot on a per-machine basis using mad scripting and rsync abuse which is even worse.
If you go out on the job market trying to hire a person for Unix workstation management that is capable of designing and running a 50+ seat shop in a cost efficient manner (which requires the list of skills described in my original GP) you will be tearing your hair out.
So it is not Linux that failed. It is the sysadmin profession. All the tools are there. Though some "corporate" oriented distributions repeatedly ship branded garbageware without testing them (at least used to). It is that the people have no idea how to use these tools.
Zenworks as far as this is a solution looking for a problem. Unix has had it solved more than 15 years ago via automounting. Any changes since have been mostly cosmetic.
As far as the complexity of the infrastructure is concerned a fully centralised infrastructure made of identical clients controlled in a single place in the center is inherently less complex to manage compared to having the settings in the clients and pushing them via a management package.
As far as storage management it is all alive and well at the server side, but it does not work out neither technically, nor financially for workstations. Once again unix has had it sorted out long ago. While we may hate NFS and AFS they do the job nicely.
And as far as sysadmins are concerned, I will repeat my statement - 95%+ of the sysadmins in the UK do not know how to run an end-user workstation installation in a corporate environment. Their knowledge and background is limited to a modern server shop where the users do not have accounts. This knowledge does not apply well to corporate workstation space.
I guess the replies in this thread prove in detail my statement about the current flock of "linux sysadmins".
Here is the detailed explanation to (1)
NIS and LDAP can both be used to ship autofs maps and the relevant databases which make out a successfull corporate deployment. Both have their limitations and while it is possible to make out a deployment with only one of them a successful big rollout needs both.
Currently only NIS can be used to limit NFS access to a specific directory to a specific machine in a centralised manner via netgroups. Unfortunately, NIS has a number of nasty problems when operating on lone machines at the end of vpn tunnels, offline, etc as well as for large scale replication. There LDAP is clearly a better solution, but it cannot provide netgroups to nss and it is also quite slow.
In order to create a scalable and maintainable large corporate deployment, $HOME (and other common shares) should be centralised on NFS (or other network FS) and accessed via an autofs mount controlled using NIS or LDAP. If implemented correctly any user can stand up, move to a different workstation sit down and start working straight away (provided that netgroup permissions allow this). All machines can be absolutely identical with no local personalisation whatsoever (even in a developer shop). Further to this, permissions, backup, maintenance are fully centralised and can scale easily into the thousands of workstations with no extra workload. Further to actual $HOMEs and shares can be migrated back and forth across the network with minimal disruption. And so on, and so forth...
In the days of SunOS and large university Unix networks any selfrespecting sysadmin knew how to do this (with Sun's automounter). Nowdays less than 5% of people claiming to be "experienced linux sysadmins" have an idea on how to do this. And that is even without going into arcane stuff like executable automounter maps and other ways to do things that are generally considered outright impossible.
There are also plenty of people who claim to be linux sysadmins or even worse - have multiple years of work experience and have no clue whatsof***ever on how to use Linux in a desktop environment. Based on interviewing people for years (in all salary brackets starting from PFY all the way to seasoned BOFHs), I have noted that in the UK the following applies to "linux sysadmins" (quotes intended):
1. Less than 5% know and understand autofs/nis|ldap/netgroups which are essential to run Linux as a corporate desktop. In fact, I have met more non-sysadmin people who do something else for a living, than "professional linux sysadmins" that know how to do this.
2. Less than 10% can read a bootlog A-Z and explain all entries.
3. Less than 10% know how to configure X.
4. Less than 5% can spec a low end system for purchasing as a dedicated desktop for Linux including checking manufacturer specs vs non-RedHat distribution requirements.
As a result it is no wonder that "a professional Linux sysadmin" cannot run Linux as a desktop. Somehow I am not surprised in the slightest.
Not quite so. Depends on the actual hell location.
If congestion hell is located on the access gear you should expect it to have the three heads of Cerberus - the loss head, the jitter head and the delay head. The reason is that the queues there are deep enough for all of these to occur.
If the hell is distributed across the backbone and the peering points drop is going to be the most likely result (the queue transmission times are not long enough to make a real influence on the other).
By the way, the really nasty hell is the access hell, not the backbone hell. Most backbones are not currently congested enough to make the backbone hell hurt so much. It will take changing capacity planning models, evaluating the new ones for stability and deploying the new models that take advantage of QoS to change this. That is not an easy task even if this is done from the top via an executive order.
Now, access (and to lesser extent peerings) is a completely different matter. There even minor QoS knob tweaking will have a major impact.
Yep, been there, seen that. I have seen SEL on fedora (4) in permissive mode still breaking an app and had it fixed by turning the damn thing off (it did work properly on Debian 4.0 though). The app was using tty functions from a web-server CGI context which is a requirement for working expect scripts.
As far as your comment on error codes and 'Permission denied by MAC policy', quite a few (if not most) of app developers do not handle all possible error codes returned by the OS and do not have a "catch-all" clause when handling errors. So returning a "new and wonderfull" error code is actually likely to cause more mayhem, than returning one of the "well known" error codes like -EACCES. I would rather have the actual error code configurable on a per-item basis (dunno if SEL can do that as I have not yet committed to the several days necessary to learn its deep internals).
Close but no cigar.
The question is: Why compare total R&D, Manufacturing and Operations budget to a lone manufacturing cost without any of the R&D and operation costs taken into account? And the answer is - because it sounds cool on Slashdot.