Feel free and encouraged to come back when you've broken AES, because that's quite literally the level of security expertise present in the team that I'm referring to.
The company I work for has a solution for that. And so do our (potential) customer companies who are already making such boxes for the many car based toll systems that have been in place in Europe for many years (check out Germany, to name just one). And so also do our competitors. We just happen to think that our solution is the best & cheapest.:-)
Believe me, I'm the project manager of the very project that developed this. The security experts working on this project are some of the very best. You'll find them also in the current NIST hash function competition (and not with an entry that was broken in just a few days).
The privacy thing is easy to fix, provided you don't rely on cameras all over the place (end even then it can be taken care of). What you need instead, is that the data of where a car has been never gets into the hands of anyone, while it is still being taken into account for cost calculations.
One way to do this, is to do the entire calculation in the car, and only transmit the accumulated cost, but this requires an in-car device that can do map matching. If those are considered too expensive, there are alternative solutions in which the map matching is done in a central data centre, while still guaranteeing that nobody can use the data to track Mr. or Mrs. Doe wherever (s)he goes. This too can be done.
PS: You do realise that if you use a cell phone, the phone company can track you on a permanent basis? Without this, they'd never be able to route calls to you.
This is the kind of system you'll find in Europe - though not only based on weight, as our governments also want to penalise environmentally unfriendly cars. But this system is also unfair, because it's a tax on owning a car, not on using it and causing wear and tear while doing so. Those who drive all day, pay just a much road tax as those who own the exact same car but only drive occasionally.
The latter is one of the reasons why on many EU countries (The Netherlands will be first to implement it) there is a desire to abolish the yearly road tax and replace it by a tax based on how much you drive. The plan is that the government will get exactly the same amount of tax many as now, but that it will be paid by the real road users. For most individual people the amount of tax to pay will actually go down.
In more advanced systems, this can also be used for traffic management: all you need to do is to make the price vary based on the kind of road or the time of day. Technically it's even quite easy to do: you need GPS, GSM, and one or more ways (there are multiple that are easy to implement) of detecting fraud. Also for maintaining privacy there are many possible solutions.
Gasoline based taxes do not offer the same flexibility.
Warning: I'm working on such a GPS/GSM based system, so it's a topic that I know quite a few things about. I guess this disqualifies me as far as posting on/. is concerned, but hey...:-)
Yep, I did something similar. Our product was controlled by a license server and I needed to generate keys for that. What I did is take the birth dates of the core team members, apply some extra macic to them that I will not explain here and bingo! Here too, they can't ever change the setup without loosing compatibility. Since then, that same server and keys have been used for other projects and I've left the company in disgust telling them to the face what I though about what they were doing wrong, but somehow they still "depend on me". If only they new...:-)
In addition, the original software generates HTML reports as part of its normal operation. Under certain conditions, it will add a picture of the development team to the report.
Think about it, the RIAA is made up of the world's most powerful record labels. They may have registered different names, but they're the same beast underneath.:)
Yes and no. Of course the RIAA and its Belgian "counterpart" SABAM are strongly linked through their members, but they're not just "the RIAA registering under a different name". SABAM was founded in 1922, and represents not only the recording industry (let alone only the US one), but also independent authors, composers, etc. In fact, one of my grandfathers - who was a composer - was one of the founding members. The problem is that in reality the small guys have no say whatsoever in this game, be they producers (with which I mean: authors & performers) or consumers of music. Only big money rules and that usually is in the hands of people who themselves don't contribute anything culturally substantial at all.
This must be one of my major pet peeves about Windows apps. The "My Documents" shit is utter nonsense. (Off-topic rant: Why would I want to store all unrelated docs together under "My Documents" and the pictures that go with one of them somewhere else like "My Pictures") But at least it is an attempt at consistent nonsense. If only the apps would stick to it, that is, but many don't! So yes, saving a doc and not knowing where has happened to me too (esp. e-mail attachments) and surely I cannot be blamed for computer ignorance (ref my sig).
Now, why most people aren't using 10.*.*.* as their internal stuff I'll never know. Since the overwhelming majority of machines on the internet aren't (and shouldn't) be directly routable, it's an awful waste to not have organizations behind NAT-ed firewalls and not drawing from the common pool of route-able IP addresses.
Mainly for historical reasons. My previous employer managed to get a B block back in the 1980s. After all, they planned on needing more than 256 addresses, so they would need it... At some point in the early 1990s, they finally managed to clean up the entire network to have logical and consistent addressing (it was a truly horrible mess before that), and since they had the B range, they used it. A few people already understood back then that this was a waste, but IT didn't listen. By now, they have many thousands of machines. All of them nicely firewalled and DMZ-ed, of course but, from an effort point of view, I can fully understand that they're not interested in changing the whole setup all over again.
I'm a busy one. If you check my comment dates. you'll see they come in batches that indicate how (un)busy I was at the time.
Oh, and I was here before the uids were introduced, so I actually have a few more.:-)
It's not because it gets sold that it gets used. I have 2 computers at home, each of which came with a Windows license (XP, back then, but the point is the same) that I paid for. But I only ever used one of these licenses (and even that machine is dual-boot). If I were to buy a new machine now, it'd surely come with Vista. But I'd never ever use the OS.
Where I work now, I have no other option than to synchronize my mailbox every 10 minutes (or manually on demand). Manual is only usable if you know you're expecting a mail really soon (like in: your room mate just sent it and you want/need it asap for some reason), so I actually want a much quicker automatic notification. Bad luck.
Where I worked before, I had a check + auto download running every 58 seconds. Yes five-eight.:-) The check used two signals: a permanent visual flag for immediately spotting new mail when I returned from a meeting or so (no matter how hidden or "down" my mail client was at the time), and an audible one triggered only if there was no unread mail before. The latter was for when I was not looking at my screen when mail arrived. If I expected something urgent, I could decide and read it immediately if I wanted, but if I decided to ignore the sound, there would be no further trigger until I unlocked my screen and would see the visual flag. This combination of two intervals worked perfectly well for me for many years. I had full control of own time management while still being able to respond within a minute or two when needed.
Back in the nineties, the company that I used to work for used to have a set of internal Usenet groups, served by the same server that provided the outside groups. The internal fora were first to be threatened as "redundant". I actually liked them a lot and actively promoted their use (also because I knew that their demise would enable killing the rest of our Usenet access). To no avail in the end: usage dropped away and at the second or third attempt, IT sadly but rightfully managed to kill them as a waste of resources. As I expected, the rest of the feed was first reduced and then killed a bit later. There simply was no interest any more.:-(
Sadly, the internal groups were never replaced by anything. No http fora, no mailing lists, no nothing.
Be all that as it may, that does not change the fact that nntp will die, whether we like it or not.
I was quite active along time ago. I started in 1988, I absolutely *loved* the whole Usenet concept, and I even co-maintained a Usenet client program, but I gradually moved away and now I can't even remember when I last connected to port 119, let alone when I last posted something.
I left because 1) http came along; and 2) all the once useful groups were getting ever more swamped by junk. Sure, a good kill file would take care of most of it, but the issue is that the number of "quality posts" went down nonetheless as people were leaving anyway. There's no real fun in seeing that there are 500 new messages in your favourite group, 480 of which get killed for being either pure spam or written by some *ssh*le who throws flames in any discussion he can find and 15 more of which don't actually add anything of value. Certainly not if you remember the times when there were "only" 100 new messages at a time of which about 40 were worth opening.
Usenet is dead (with or without film at 11). Old people stop using it. New ones don't even start. Yes, this really means that it's an economical waste for ISPs (and others), so yes they do have a bit of reason to close it down, whether we like it or not. Face it, this is a spiral from which there is no escape. And it's not even unexpected: every technology, system, or even state eventually dies.
It's easier to convert 50% of 10 than 50% of 10000000000000000000.
Please note that I know there are more then 10 Firefox users out there and all that yadayada. And that I'm a big fan of Open Source, using a Mozilla based browser myself. All I'm doing is pointing out the low quality of the anti-MS FUD that is being spread here. We don't need this kind of sensationalist reasoning/reporting to beat MicroSoft, we should (and can) do that on value and merit!
I don't care whether the feature was there before: it should just work. And I actually even don't care that much about using flash (although flash does have a tendency to hang my browser, so static pages are still better). It's the "we don't support Linux" thing that really p*sses me off.
Here's what I sent them earlier on when discovering that part of the site even does not support Linux:
I really can't believe you show such a big lack of understanding of your
target audience. Dilbert & Co. are engineers. Engineers read Dilbert
because of how much it reflects the silly issues they face every day when
dealing with clueless managers, marketeers, etc. It helps them to have a
smile on their face in the face of office misery.
And then what do we get? A Dilbert site update that does not support Linux.
In 2008. Guess what? Engineers use Linux. I've fought my PHBs for the right
to do so back in 1999 and I won. About the whole department has been
Linux-on-the-desktop ever since...
My MBA (yes, I have one of those as well and yet I still use Linux) tells
me that you're making a classical mistake of many companies that once were
successful. Note the tense of that!
April 17, 2008: A day that will live in infamy.
And that's just one of my gripes. The new UI is clunky; the site is slow;...
Yes, but how many of the watertight compartments were damaged/flooded and which ones? Titanic had too many compartments damaged to stay afloat and the fact that these were all at the same end of the ship didn't exactly help either (tilting her up to the point where the water could overflow the bulkheads). My guess is Olymopic had less damaged/flooded compartments. That, plus the fact that Olympic was partly rebuilt after the Titanic disaster had exposed certain design defects in the class.
I don't have a lot of time right now - and I don't know your specific situation - but here are some thoughts:
It will require some commitment from your superusers. If they do not have time, it will require commitment from management to make some time. Without this you're doomed to fail, as you'll risk sending the wrong messages to the IT guys. This does not have to imply that the superusers take over IT workload on a more permanent basis (I did, as did some of my fellow superusers, but not all of us did). Doing some things "together" was part of making it a team. But then again, if a superuser is more than just very knowledgable, (s)he is active already and thus already doing part of the IT job. In that case, it's not an extra workload, but one that can actually be reduced if you can get IT to support the idea in wasy that the users are happy with or at least can live with.
One specific thing we did that helped a lot, was to move a UNIX admin who was working as a shadow (with root access) from the user side to IT, making it very clear that we as users are not after their jobs, and on the contrary were willing to give them back control they had previously lost as a consequence of all the wars. It will help a lot if you can find something like this too.
This may or may not apply to you: Try to organise the setup such that not everyone needs to be in on everything. People don't have the time for that, and in general are not superusers at all levels or in all areas anyway. We had a split in a UNIX working group (worked very well), a PC working group (worked less well, partly because we did not find a good chair(wo)man), and an overall one (worked OK). Had we tried to do everything-in-one, I'm sure it would have worked less well overall.
The venting of frustrations is likely to be around for some time. In our case it also took a few years to fully eliminate of it. The person in charge of the action must be a strong leader and a good diplomat at the same time to resolve this asap. (Note: Back when I co-kicked-off this thing, I was not suitable material: I was too young to be diplomatic in these matters and so far had been part of the fight, which is why we specifically chose a more neutral person to chair the working group for the first few years. De-facto, that person was not IT savvy, so from a purely technical point of view, he basically was mostly steered by me and two fellow group members. But he sure was good at dealing with that - stopping us when we went too far - and he did have a lot of credibility of meaning well for the organisation. By the time I took over, I had calmed down a bit and proven my technical as well as non-technical skills.)
Very important is that the people are willing to consider the opposite point of view and even defend it. I was a user representative and as such every other month or so I got some request from my community that did not make sense or that made theoretical sense but could not be implemented for some solid practical reason. In cases like these, I did not hesitate to side with IT and explain their p.o.v. back to my constituency. This created a lot of good will on the IT side, which then enabled me to get things done that they otherwise would not have accepted. That in turn caused my constituency to accept it when I told them that they would not get their latest and greatest fad by tomorrow. By the way: My IT counterparts were equally good at this. If a user request was reasonable, they too had the courage to go to their management and/or their team and support our point of view. That's, for instance, how we as users got Linux accepted as a fully supported desktop platform against the wishes of our very much pro-MicroSoft CIO: in our business (EDA) we just needed either UNIX (what we had up to then) or Linux.
First of all, it depends on the context whether this is a good idea or not. In some environments, the IT group is the one and only IT wizard. In others (esp. in companies where IT development and IT research are the core business), the official IT group often is not at all capable of even understanding what the engineers are doing and supposed to do.
I've always worked (nearly 18 years now) in the latter situation. Once upon a time, I was one of those superusers in that I was had an IT degree, but worked in engineering (research, actually) where most of my collegues were non-IT engineers. They were very IT savy at a personal level, but generally missed the wider scope. So far so good. The not so good thing, was that the IT department had no clue whatsoever of what the real business needs in terms of IT were (and neither had the company's management). The consequence was an ever worsening war between IT and IT users, amongst other things resulting in ever more shadow systems. We solved this by establishing a working group that took care ensuring there regular was bidirectional communication between parties (I was one of the founding fathers and later on was the chairman for many years). This worked wonders. (Note: It worked so well, that when I finally left the company, the IT group tried to convince me to stay by proposing that I might join them in quite senior positions.)
Part of the whole concept was to do exactly what TFA says: the real superusers were identified; they earned the trust/respect they deserved; and then gained the appropriate - for our context - access to specific systems. (I personally managed the whole repository of OSS as well as some commercial soft we had installed centrally on UNIX. No, I did not have root, as I designed the complete setup such that I did not need it, but it will also be clear that with that level of access I potentially could access a lot of data and that capturing root would not have been difficult had I wanted. Some superusers can be trusted afterall.) Many succesful applications were developed in the same way: some superuser developed - with the knowledge of IT - a prototype that was taken into production for a larger audience after review by the working group and possibly some clean up by IT.
Actually, all this is nothing new. Strategic alignment between business and IT is a core part of IT governance. So is making sure that IT governance is not a buzzword hidden in a bi-monthly meeting between the CTO and CIO, both of whom generally do not understand the issues, but that it is something that is built into the whole system at all levels. And yes, this includes the superusers (at least the capable ones).
Concluding remark: I've since obtained an MBA. As part of the IT course, I wrote a paper describing the complete history of IT management & governance at my previous employer detailing the above story at length. That paper made a very happy professor, as he considered that I was absolutely spot on. Afterwards he started using me as an in-class assistant for the remainder of his course.
... supporters of calls for more sharing of data argue that apparently trivial snippets - like the journeys an individual makes around the capital - could become important pieces of the jigsaw when fitted into a pattern of other publicly held information on an individual's movements, habits, education and other personal details. That could lead, they argue, to the unmasking of otherwise undetected suspects."
As an opponent of calls for more sharing of data I argue that apparently trivial snippets - like the journeys an individual makes around the capital - could become important pieces of the jigsaw when fitted into a pattern of other publicly held information on an individual's movements, habits, education and other personal details. Are we sure we really want this?
The issue is not even so much that data is being - or can be - collected. The real issue is that, as soon as data that previously was not available becomes available, some party will want to access it. Parties such as MI5 are lucky in that they have it easy to get what they want, but they are not even my main concern (yet). When collecting data that can result in privacy breaches, one should not limit oneself to looking at those parties that may have a legitimate motivation for wanting access and may be willing to play by the (current) book (for now). Once the data set is there, any (future) government agency becomes a potential abuser. This includes those formed or reformed after a change of regime: please be aware that democracy has a key flaw: it can be used to abolish itself!
We like challenges and challengers too. :-)
Feel free and encouraged to come back when you've broken AES, because that's quite literally the level of security expertise present in the team that I'm referring to.
No. There is no technical need to send the location info to the government. Nor even to a private organisation.
Right. But that's exactly what is being planned all over the place as I write.
The company I work for has a solution for that. And so do our (potential) customer companies who are already making such boxes for the many car based toll systems that have been in place in Europe for many years (check out Germany, to name just one). And so also do our competitors. We just happen to think that our solution is the best & cheapest. :-)
Believe me, I'm the project manager of the very project that developed this. The security experts working on this project are some of the very best. You'll find them also in the current NIST hash function competition (and not with an entry that was broken in just a few days).
The privacy thing is easy to fix, provided you don't rely on cameras all over the place (end even then it can be taken care of). What you need instead, is that the data of where a car has been never gets into the hands of anyone, while it is still being taken into account for cost calculations.
One way to do this, is to do the entire calculation in the car, and only transmit the accumulated cost, but this requires an in-car device that can do map matching. If those are considered too expensive, there are alternative solutions in which the map matching is done in a central data centre, while still guaranteeing that nobody can use the data to track Mr. or Mrs. Doe wherever (s)he goes. This too can be done.
PS: You do realise that if you use a cell phone, the phone company can track you on a permanent basis? Without this, they'd never be able to route calls to you.
This is the kind of system you'll find in Europe - though not only based on weight, as our governments also want to penalise environmentally unfriendly cars. But this system is also unfair, because it's a tax on owning a car, not on using it and causing wear and tear while doing so. Those who drive all day, pay just a much road tax as those who own the exact same car but only drive occasionally.
The latter is one of the reasons why on many EU countries (The Netherlands will be first to implement it) there is a desire to abolish the yearly road tax and replace it by a tax based on how much you drive. The plan is that the government will get exactly the same amount of tax many as now, but that it will be paid by the real road users. For most individual people the amount of tax to pay will actually go down.
In more advanced systems, this can also be used for traffic management: all you need to do is to make the price vary based on the kind of road or the time of day. Technically it's even quite easy to do: you need GPS, GSM, and one or more ways (there are multiple that are easy to implement) of detecting fraud. Also for maintaining privacy there are many possible solutions.
Gasoline based taxes do not offer the same flexibility.
Warning: I'm working on such a GPS/GSM based system, so it's a topic that I know quite a few things about. I guess this disqualifies me as far as posting on /. is concerned, but hey... :-)
x.
Yep, I did something similar. Our product was controlled by a license server and I needed to generate keys for that. What I did is take the birth dates of the core team members, apply some extra macic to them that I will not explain here and bingo! Here too, they can't ever change the setup without loosing compatibility. Since then, that same server and keys have been used for other projects and I've left the company in disgust telling them to the face what I though about what they were doing wrong, but somehow they still "depend on me". If only they new... :-)
In addition, the original software generates HTML reports as part of its normal operation. Under certain conditions, it will add a picture of the development team to the report.
Think about it, the RIAA is made up of the world's most powerful record labels. They may have registered different names, but they're the same beast underneath. :)
Yes and no. Of course the RIAA and its Belgian "counterpart" SABAM are strongly linked through their members, but they're not just "the RIAA registering under a different name". SABAM was founded in 1922, and represents not only the recording industry (let alone only the US one), but also independent authors, composers, etc. In fact, one of my grandfathers - who was a composer - was one of the founding members. The problem is that in reality the small guys have no say whatsoever in this game, be they producers (with which I mean: authors & performers) or consumers of music. Only big money rules and that usually is in the hands of people who themselves don't contribute anything culturally substantial at all.
Hear, hear.
This must be one of my major pet peeves about Windows apps. The "My Documents" shit is utter nonsense. (Off-topic rant: Why would I want to store all unrelated docs together under "My Documents" and the pictures that go with one of them somewhere else like "My Pictures") But at least it is an attempt at consistent nonsense. If only the apps would stick to it, that is, but many don't! So yes, saving a doc and not knowing where has happened to me too (esp. e-mail attachments) and surely I cannot be blamed for computer ignorance (ref my sig).
Now, why most people aren't using 10.*.*.* as their internal stuff I'll never know. Since the overwhelming majority of machines on the internet aren't (and shouldn't) be directly routable, it's an awful waste to not have organizations behind NAT-ed firewalls and not drawing from the common pool of route-able IP addresses.
Mainly for historical reasons. My previous employer managed to get a B block back in the 1980s. After all, they planned on needing more than 256 addresses, so they would need it... At some point in the early 1990s, they finally managed to clean up the entire network to have logical and consistent addressing (it was a truly horrible mess before that), and since they had the B range, they used it. A few people already understood back then that this was a waste, but IT didn't listen. By now, they have many thousands of machines. All of them nicely firewalled and DMZ-ed, of course but, from an effort point of view, I can fully understand that they're not interested in changing the whole setup all over again.
I'm a busy one. If you check my comment dates. you'll see they come in batches that indicate how (un)busy I was at the time. Oh, and I was here before the uids were introduced, so I actually have a few more. :-)
That is easy to fix. Put the cap at 509 and exclude no. 56. The size of the remaining crowd would be about the same in both cases anyhow.
It's not because it gets sold that it gets used. I have 2 computers at home, each of which came with a Windows license (XP, back then, but the point is the same) that I paid for. But I only ever used one of these licenses (and even that machine is dual-boot). If I were to buy a new machine now, it'd surely come with Vista. But I'd never ever use the OS.
Indeed.
Where I work now, I have no other option than to synchronize my mailbox every 10 minutes (or manually on demand). Manual is only usable if you know you're expecting a mail really soon (like in: your room mate just sent it and you want/need it asap for some reason), so I actually want a much quicker automatic notification. Bad luck.
Where I worked before, I had a check + auto download running every 58 seconds. Yes five-eight. :-) The check used two signals: a permanent visual flag for immediately spotting new mail when I returned from a meeting or so (no matter how hidden or "down" my mail client was at the time), and an audible one triggered only if there was no unread mail before. The latter was for when I was not looking at my screen when mail arrived. If I expected something urgent, I could decide and read it immediately if I wanted, but if I decided to ignore the sound, there would be no further trigger until I unlocked my screen and would see the visual flag. This combination of two intervals worked perfectly well for me for many years. I had full control of own time management while still being able to respond within a minute or two when needed.
Back in the nineties, the company that I used to work for used to have a set of internal Usenet groups, served by the same server that provided the outside groups. The internal fora were first to be threatened as "redundant". I actually liked them a lot and actively promoted their use (also because I knew that their demise would enable killing the rest of our Usenet access). To no avail in the end: usage dropped away and at the second or third attempt, IT sadly but rightfully managed to kill them as a waste of resources. As I expected, the rest of the feed was first reduced and then killed a bit later. There simply was no interest any more. :-(
Sadly, the internal groups were never replaced by anything. No http fora, no mailing lists, no nothing.
Be all that as it may, that does not change the fact that nntp will die, whether we like it or not.
I was quite active along time ago. I started in 1988, I absolutely *loved* the whole Usenet concept, and I even co-maintained a Usenet client program, but I gradually moved away and now I can't even remember when I last connected to port 119, let alone when I last posted something.
I left because 1) http came along; and 2) all the once useful groups were getting ever more swamped by junk. Sure, a good kill file would take care of most of it, but the issue is that the number of "quality posts" went down nonetheless as people were leaving anyway. There's no real fun in seeing that there are 500 new messages in your favourite group, 480 of which get killed for being either pure spam or written by some *ssh*le who throws flames in any discussion he can find and 15 more of which don't actually add anything of value. Certainly not if you remember the times when there were "only" 100 new messages at a time of which about 40 were worth opening.
Usenet is dead (with or without film at 11). Old people stop using it. New ones don't even start. Yes, this really means that it's an economical waste for ISPs (and others), so yes they do have a bit of reason to close it down, whether we like it or not. Face it, this is a spiral from which there is no escape. And it's not even unexpected: every technology, system, or even state eventually dies.
It's easier to convert 50% of 10 than 50% of 10000000000000000000.
Please note that I know there are more then 10 Firefox users out there and all that yadayada. And that I'm a big fan of Open Source, using a Mozilla based browser myself. All I'm doing is pointing out the low quality of the anti-MS FUD that is being spread here. We don't need this kind of sensationalist reasoning/reporting to beat MicroSoft, we should (and can) do that on value and merit!
I don't care whether the feature was there before: it should just work. And I actually even don't care that much about using flash (although flash does have a tendency to hang my browser, so static pages are still better). It's the "we don't support Linux" thing that really p*sses me off.
For the non-working bit, try the animated strips section. I'd post a link, but for some reason I'm now seeing the old site again...
Here's what I sent them earlier on when discovering that part of the site even does not support Linux:
And that's just one of my gripes. The new UI is clunky; the site is slow; ...
Yes, but how many of the watertight compartments were damaged/flooded and which ones? Titanic had too many compartments damaged to stay afloat and the fact that these were all at the same end of the ship didn't exactly help either (tilting her up to the point where the water could overflow the bulkheads). My guess is Olymopic had less damaged/flooded compartments. That, plus the fact that Olympic was partly rebuilt after the Titanic disaster had exposed certain design defects in the class.
I don't have a lot of time right now - and I don't know your specific situation - but here are some thoughts:
It will require some commitment from your superusers. If they do not have time, it will require commitment from management to make some time. Without this you're doomed to fail, as you'll risk sending the wrong messages to the IT guys. This does not have to imply that the superusers take over IT workload on a more permanent basis (I did, as did some of my fellow superusers, but not all of us did). Doing some things "together" was part of making it a team. But then again, if a superuser is more than just very knowledgable, (s)he is active already and thus already doing part of the IT job. In that case, it's not an extra workload, but one that can actually be reduced if you can get IT to support the idea in wasy that the users are happy with or at least can live with.
One specific thing we did that helped a lot, was to move a UNIX admin who was working as a shadow (with root access) from the user side to IT, making it very clear that we as users are not after their jobs, and on the contrary were willing to give them back control they had previously lost as a consequence of all the wars. It will help a lot if you can find something like this too.
This may or may not apply to you: Try to organise the setup such that not everyone needs to be in on everything. People don't have the time for that, and in general are not superusers at all levels or in all areas anyway. We had a split in a UNIX working group (worked very well), a PC working group (worked less well, partly because we did not find a good chair(wo)man), and an overall one (worked OK). Had we tried to do everything-in-one, I'm sure it would have worked less well overall.
The venting of frustrations is likely to be around for some time. In our case it also took a few years to fully eliminate of it. The person in charge of the action must be a strong leader and a good diplomat at the same time to resolve this asap. (Note: Back when I co-kicked-off this thing, I was not suitable material: I was too young to be diplomatic in these matters and so far had been part of the fight, which is why we specifically chose a more neutral person to chair the working group for the first few years. De-facto, that person was not IT savvy, so from a purely technical point of view, he basically was mostly steered by me and two fellow group members. But he sure was good at dealing with that - stopping us when we went too far - and he did have a lot of credibility of meaning well for the organisation. By the time I took over, I had calmed down a bit and proven my technical as well as non-technical skills.)
Very important is that the people are willing to consider the opposite point of view and even defend it. I was a user representative and as such every other month or so I got some request from my community that did not make sense or that made theoretical sense but could not be implemented for some solid practical reason. In cases like these, I did not hesitate to side with IT and explain their p.o.v. back to my constituency. This created a lot of good will on the IT side, which then enabled me to get things done that they otherwise would not have accepted. That in turn caused my constituency to accept it when I told them that they would not get their latest and greatest fad by tomorrow. By the way: My IT counterparts were equally good at this. If a user request was reasonable, they too had the courage to go to their management and/or their team and support our point of view. That's, for instance, how we as users got Linux accepted as a fully supported desktop platform against the wishes of our very much pro-MicroSoft CIO: in our business (EDA) we just needed either UNIX (what we had up to then) or Linux.
... (sorry, gotta run now)
First of all, it depends on the context whether this is a good idea or not. In some environments, the IT group is the one and only IT wizard. In others (esp. in companies where IT development and IT research are the core business), the official IT group often is not at all capable of even understanding what the engineers are doing and supposed to do.
I've always worked (nearly 18 years now) in the latter situation. Once upon a time, I was one of those superusers in that I was had an IT degree, but worked in engineering (research, actually) where most of my collegues were non-IT engineers. They were very IT savy at a personal level, but generally missed the wider scope. So far so good. The not so good thing, was that the IT department had no clue whatsoever of what the real business needs in terms of IT were (and neither had the company's management). The consequence was an ever worsening war between IT and IT users, amongst other things resulting in ever more shadow systems. We solved this by establishing a working group that took care ensuring there regular was bidirectional communication between parties (I was one of the founding fathers and later on was the chairman for many years). This worked wonders. (Note: It worked so well, that when I finally left the company, the IT group tried to convince me to stay by proposing that I might join them in quite senior positions.)
Part of the whole concept was to do exactly what TFA says: the real superusers were identified; they earned the trust/respect they deserved; and then gained the appropriate - for our context - access to specific systems. (I personally managed the whole repository of OSS as well as some commercial soft we had installed centrally on UNIX. No, I did not have root, as I designed the complete setup such that I did not need it, but it will also be clear that with that level of access I potentially could access a lot of data and that capturing root would not have been difficult had I wanted. Some superusers can be trusted afterall.) Many succesful applications were developed in the same way: some superuser developed - with the knowledge of IT - a prototype that was taken into production for a larger audience after review by the working group and possibly some clean up by IT.
Actually, all this is nothing new. Strategic alignment between business and IT is a core part of IT governance. So is making sure that IT governance is not a buzzword hidden in a bi-monthly meeting between the CTO and CIO, both of whom generally do not understand the issues, but that it is something that is built into the whole system at all levels. And yes, this includes the superusers (at least the capable ones).
Concluding remark: I've since obtained an MBA. As part of the IT course, I wrote a paper describing the complete history of IT management & governance at my previous employer detailing the above story at length. That paper made a very happy professor, as he considered that I was absolutely spot on. Afterwards he started using me as an in-class assistant for the remainder of his course.
From TFI (TF Intro):
As an opponent of calls for more sharing of data I argue that apparently trivial snippets - like the journeys an individual makes around the capital - could become important pieces of the jigsaw when fitted into a pattern of other publicly held information on an individual's movements, habits, education and other personal details. Are we sure we really want this?
The issue is not even so much that data is being - or can be - collected. The real issue is that, as soon as data that previously was not available becomes available, some party will want to access it. Parties such as MI5 are lucky in that they have it easy to get what they want, but they are not even my main concern (yet). When collecting data that can result in privacy breaches, one should not limit oneself to looking at those parties that may have a legitimate motivation for wanting access and may be willing to play by the (current) book (for now). Once the data set is there, any (future) government agency becomes a potential abuser. This includes those formed or reformed after a change of regime: please be aware that democracy has a key flaw: it can be used to abolish itself!