...in fact, I saw this news item in my RSS reader, Feedly.

I can't think of a web site that I use regularly that doesn't provide a RSS feed.

The real story here is that Shared Services was set up to fail almost from the beginning. While the idea of centralized IT is probably a good one from a reducing-duplication standpoint (at the expense of an increasing-bureaucracy standpoint); Shared Services Canada's budget was cut before it was even half-formed, and then cut again in subsequent years (see this November 2016 Ottawa Citizen article: http://ottawacitizen.com/news/...). So of course they are failing to deliver. So while it may be fun to say "Feds Screw Up IT Again, Hurr Durr" let's be sure to blame the real problem makers -- the politicians, mostly Conservative, who dug this hole that Shared Services finds itself in.

The biggest problem with public transportation is, and always will be, the public.

Part of my job is to advise companies on security policies like this, and I have advised in favor of such restrictions when asked. However this is done out of respect for the end-user's privacy. The reasoning is that there are two conflicting priorities in permitting BYOD use and network access:

First, as a security officer I have a duty to ensure that the network and all devices connected to it remain secure.

Second, as an agent of the company I have absolutely no right to dictate to an employee what they must or must not do with their device to prove that it is secure. It is their device which they purchased with their money to use for their own purposes.

Since I cannot prove that the device is secure without violating their privacy or exerting an unreasonable amount of control over the device, the only resolution is that the device is not permitted.

If you really need a device, then the resolution to that is to get the company to buy you a device -- at which point the company owns it, and can dictate what security measures are taken.

At the end of the day, a company pays you to do a job, and as such has the final say over how you do it and what tools you use to do it. It may not be your choice, or the best choice, or even an efficient choice. But that's how they want it done.

Good employers will listen to their staff and make adjustments and get the tools that their staff need. But it isn't mandatory.

If you don't like the job, and the employer won't change it to suit you, you have two choices: live with it, or leave.

Been there. Done that. Failed repeatedly, and for various interesting reasons, none of which are generalizable.

Your problem has several aspects to it, and as far as I can nobody's talked about them. Lots of the answers talk about specific parts of the problem but not in a general way.

Here's your problem:

• Figure out what you have: this is a basic inventory.
• Figure out how it is connected together: this is a wiring table. Some people will tell you that a wiring diagram is good enough, but after a certain point you can't use them because they get too big and the layout problems start to get non-trivial. So you need a table. Which means you need a way to identify each wire. At both ends. Uniquely. Accurately.
• Figure out how to store it all. Visio for simple, high-architecture diagrams, yes. We use Sharepoint and custom tables for the actual device and wiring tables, but Excel will do. There's a whole essay that could be written on this (and I feel like I've written parts of it repeatedly) but the #1 aspect to this issue is that WHATEVER YOU PICK HAS TO BE SIMPLE AND STAY OUT OF PEOPLE'S WAY OR THEY WON'T USE IT. You have to make it trivial to keep the data up to date. You have to somehow make it harder to not do the wrong thing -- but since the wrong thing is to ignore the documentation and just slap your wire in there, that's impossible. Which means you need:
• A way to detect changes that are made without authorization. I have a home grown collection of tools (rancid, nagios, arpwatch) and scripts that detect most of the day-to-day possible changes that happen on my particular network. I like the idea of NetDisco but have never achieved a working instance. The problem is that while detecting adds and moves is easy (because a move appears as an add) detecting decommissioning is hard. So the documentation rots. So you need:
• Tools that can detect the current state of the network. One of my copious-spare-time project (for the last ten years *sob*) has been writing a perl script that can query my snmp switches and tell me what port a particular MAC address is connected to, right now. I can't tell you how many times that script has saved hours of f---ing around at various places. But you need SNMP-manageable gear for something like that to work. So you need:
• Management that will support you in this endeavor. Management that will spend the extra bucks to ensure that equiptment can be monitored for changes by external systems. Management that understands that documentation needs periodic auditing and that the crazy guy ranting about unauthorized changes has been empowered by management to enforce documentation about these changes. (Which is hard when its your boss making the changes.)

Frankly the last issue is the most important. If you can get management to sign off on spending money (and really, your time is their money) then you are 50% of the way home. If you get sandbagged halfway through when you discover you need to unplug three linksys switches that happen to form the iSCSI core network that will take the world offline for six hours to sort out a spanning-tree loop, then you'll have other problems. But the technical ones are easy to sort out once management has committed to spending time and money to solve them.

Because Gnome is the default. I have to touch dozens of computers in a week, many of them freshly built, and I gave up trying to customize all of them a long time ago. Basically the only thing I customize now is the .bash_profile and the .vimrc -- both of which can be wget'd trivially quickly. I don't have time to fuck around with window managers any more.

This doesn't work for the same reason that virtualization rarely yields absolute savings. Instead of "doing the same with less", the pointy heads see all this newly-freed up hardware and decide to re-use it. You end up "doing even more with the same". So your costs-per-work-unit go down, but your absolute costs stay the same (or go up once virtualization costs are factored in).

The same goes for people buying hardware. We rarely say "oh, I can buy this computer that has A) the same performance and B) better energy consuption rates as my existing one for less than I paid for it" -- we say "oh, I can buy one that is so much faster and powerful (and ususally, energy-hungry) than my existing one for the same as I paid for the originial".

Why spend more money to get what you already have, when you can spend more money to get -- more?

Don't be stupid. You very well know that that iPad is worth, at most, $1000, while a single downloaded song is worth easilly ten times that much.

It is all about putting policing resources where they will generate the most revenue for the politicians^W^W^W^W^W^W^W do the most good.

You guys all remember that we read this back in 2010, right?

I mean, s/Fark/Gawker/ and all that, the only notable difference is that the Fark guy said only 1% of the comments were worth anything, while the Gawker guy says 1 in 5. Which would be a huge improvement if it had any basis in reality.

What happens when he's on vacation or sick and a server dies? What happens when the website has an issue and then *anything* else goes wrong?

Oh, that's easy:

• He gets called in from being on vacation or sick;
• he gets to work uncompensated time to fix the problem;
• if he fails to either respond to the call OR fails to fix the problem, he gets fired;
• if he succeeds in fixing the problem, he gets threatened with termination should something else fail while he's "unavailable".

In fact, I'd lay odds that's how the vacancy occurred.

It is more subtle than that. The problem is that the "freedom" being exercised in the current ecosystem is that of the Software Engineer: they have the freedom to write bad applications (or write good applications badly, which is different). The end result is that the end user no longer cares if you, the Software Engineer has unfettered market access to their device. They are tired of dealing with the garbage that the unfettered market is providing. They don't want freedom -- they want to do the things that these devices are supposed to enable, instead of being hung up on the devices themselves. For example, the difference between operating a camera and taking a picture.

Your reply also confuses me, as you seem to take a position against mine, then go on to use your own poor experiences with your non-restricted Android platform as an argument -- which to my mind, just reinforces my argument. If someone had been curating your app experience with the Android, it might not have been so bad.

Apple's App Store is a logical result of the chaos that's been exhibited on general purpose computing platforms for the last 20 years.

When end users experience crashes, blue screens, data corruptions, poor user interfaces, hung devices, and insufficient functionality, they are not "feeling their freedom". They are feeling the results of you exercising yours. And when their "local nerd" is asking them questions which leadingly suggest that they shouldn't have been doing what they've been doing, they feel angry.

End users want computing like they want toast. Put in their bread/data, push a button, and get their toast/video. The fact that this is very hard, and in some cases virtually impossible, does nothing to limit the end users' expectations. For years they have been told these computers will make their lives better and enable them in so many ways -- which they have, but they sure don't like the hidden costs that these ecosystems have dumped on them.

You know all those arguments that have been made? If you don't like it, you don't have to use it! That's all the end user is doing.

Sturgeon's Law explains that 90% of anything is crap. If curation -- in the form of App Stores or whatever -- can change those odds, even just a little bit, end users are going to move towards them in droves.

Software engineers have squandered their freedom, and end users are increasingly acting like they don't want to have any part of it any more.

(I wrote up a much longer article on the same theme.)

[...] except now you have to pay that same netadmin outrageous consulting wages 'cuz he's not on the payroll.

You know, that's exactly the argument I use with my customers. When something breaks, yes, you pay me more per hour than you'd pay someone you have onhand full time. However, I know for a fact you don't have enough work for a full-time body, therefore every hour I'm not here you pay me less than you'd pay someone you have onhand full time. Since (for these customers) there are hugely more of the latter than the former, I'm a better deal than the full-timer -- up to a certain point, when I can help you transition to a full-timer instead of using me.

And even better, if things break so hard you need two or three or more sets of hands to put things right, I can "scale up" faster and cheaper than looking for more full-timers.

When people say that open source lets people do more with less, they lose sight of the fact that it is the businesses doing the more. The fact it is with less IT/ICT -- that's business. Its no different -- and should be mourned no more -- than all those photocopiers putting typing pools surplus to requirements.

I hate you, I hate you, I hate you.

Not only did I think Self, that assertion about running Windows98 on a 286 sounds incorrect, I was sure that Windows95 and higher required the 386 protected mode instruction set, which in and of itself is painful, but I actually wasted time googling Windows98 system requirements, where I found this page at microsoft, which reads in part:

A personal computer with a 486DX 66 megahertz (MHz) or faster processor (Pentium central processing unit recommended).

Oh my god I hate you. Perhaps almost as much as I hate myself... but that's a different problem.

I use a Linux router running nfsen on the internal interface. From there I can set filters that count flows, bytes, and packets in and out of the router. (I can also go back in later and look at who was doing what if the resulting graphs look funny.)

I don't expect the numbers that I get to match what my provider's say; I just expect that if they claim I am over, I will be able to confirm that (within certain loose percentages) and then figure out why I am over.