How about supporting open source besides fifty shades of the same thing? Like, porting one or more *BSDs to POWER 8?

There really is more to open source OSes than just "linux", you know.

Set policy. Like, you have a list of recommended software. I'd say at least two browsers and a bunch of utility software. You support those, and beyond that it's best-effort. Curate the collection. With a clear idea of what's in use, you can even start to assemble the whole thing from FOSS and eventually move to a non-proprietary OS to underpin the tools. But that really is but a side-effect of having a good grasp of the needs of your shop. See the LiMux project.

Communicate. Not just this one thing, your entire policy, FAQs, tips and tricks, what-have-you. An internal website will do. A wiki is great for this*, even if you're not opening up editing to others. But you could do that for selected parts too. Make sure everybody knows where the fount of (IT) wisdom is to be found. You don't have to be pushy about getting people to use it; even helpdeskers reading ready-made solutions to panicked people is better than having them making up answers on the spot, though this is only true if the ready-made stuff is of good quality. And if it applies to the situation, but that's the helpdesker's job to workout. So make a point of both having helpdeskers add questions and of curating the material, so you both know what's popular and that they have decent answers.

Most of all, don't get condescending; write *for* the reader, not *at* them, or worse, refer to them as "the user", like so many programmers do. Who're they writing their software for, anyway?

Once that's going you can even expand into short tutorials**, book reviews to help pick up more skills, and so on. But let's get the basics going first.

Notice that if you have your shop organised with ready-made software and information answers, people will have a well-known point to look at in case of panic. So with that in hand, in case of big trouble you can send out word with a recommendation to review the latest news in the usual places where all the details can be found, with a short abstract with enough information --accessible to them-- to let them make a "should I spend time on this now? can it wait until later?" decision.

Don't try to force people's hands until and unless absolutely necessary. Give them the tools and the right information on the right time to let them make meaningful decisions. This requires not so much serious writing skill (though it helps), but putting yourself in their perspective. "I don't understand all this, why do I need to bother?"

* Plenty wiki software available. I like dokuwiki and dislike mediawiki because syntax, which I think is important as it is a tool to express and so convey the message. At minimum go for CREOLE support.
** A tutorial isn't a tutorial unless it also tells how to recover from mishaps. Most "tutorial" blogposts fail at this and as such are not worthy of the name.

If he's honest, he'd say exactly that. If he's dishonest, he'd either waffle or again say exactly that. If he's planting for some secret service he'd also say exactly that. Only one of the cases I'd take my hat off for. Worse, this guy made his academic career out of "security" protocols but gets blind-sided by a "honest mistake", and only one casual reviewer didn't spot it either. That really isn't good enough, neither for him nor for the openssl project, or any widely-used security-heavy piece of software.

Perhaps more importantly, it shows the dangers of poor protocol design. I'm not too versed in the intricacies of this one, but I can't help but wonder why it needed two length fields, and why you even have one if you're not going to check them.

The trick is to only look at the input once it's assumption-free, ie all necessary assumptions are known and have been checked to hold. That way you don't have to juggle one (or two, or N) length fields and hope you have the right one.

I think our dear honestly mistaken holder of a PhD in computer security has a bit more soul searching to do. As does the openssl team.

No, I'm not advocating more layers upon layers of software, I'm advocating better design in protocol and software*, better code review and code acceptance practices, and understanding things like line coding before tinkering with any protocol, much less a security-sensitive one. Like, oh, openssl.

* There's also Theo's (of TheoBSD fame) observation that openssl bypasses security measures available in certain malloc/free implementations by dint of defaulting on all platforms to their own allocator without such features because on some (other) platforms malloc is "slow". Worse, turning that "feature" off breaks openssl because the team hasn't tested without it. Looks like there's room for improvement with the unit testing practices too.

The efficacy of community building by reinforcing your shared hate of a common enemy notwithstanding, I don't think that's what creationists are doing.

Rather, they've picked up on something that's been happening for a while: The (ab)use of "science"(-y sauce) as underpinning and justification of policy by a loose group of people that have not too much truck with democracy but are well-moneyed and well-positioned for lobbying. You can see it, for example, in the doings of and influence that certain large advertisement and "social networking" companies have with the current USA administration.

It has been going on for a while, and it's supplanting the influence a different group had, that're now mounting a counter-campaign with an "updated" variation of their own ideology. And, evidently, with success.

It doesn't help that the "publish or perish" rat race has caused plenty of "science" to, often invisibly for many years, hopelessly derail into cherry-picking outcomes, even making up data, and writing, massaging, and otherwise manipulating towards a desirable result or at least away from an undesirable result. This too opened the door for creationists making up fantasy and writing their way toward their desired conclusions "scientifically". This isn't how science is supposed to work, but as long as it does, it has very little counter against creationism.

The kicker here is to realise that in their eyes it's the science-ists that are over-reaching into their turf and so they strike back, however opaquely and convolutedly. In that sense, the FSM is a nice satire but one that misses the underlying raison d'etre for creationism entirely.

Personally I think both the abuse of science for justifying your personal agenda and the christianity-flavoured counter are deeply flawed and undesirable drivers of policy, though I'll still happily wear a colander for my passport photos. And at the same time I don't have a ready-made "better" ideology to shove into the fray to cool everyone down a bit. I do say that if it needs belief to function, it's not science. This is evidently hard on many people.

All I can do for now is point out what's happening, and that it is very counter-productive for the progress of human achievement to, effectively, try and worship science. Science shouldn't be used as a "shut up you I'm right" argument and so a counter with "no my ideology is better than yours, really" shouldn't even be possible. So this underdog play for "equal airtime" should be immediately laughable on its face. The apparent fact that it isn't, means they're not losing.

Kudos for staying under budget, Estonia. But let's look at what we have here. An easy-to-use, ubiquitous identity solution that's easily integrated everywhere?

Sounds cool, right? But only if you trust your government, and every government thereafter. With small countries (Estonia, Iceland) this is much easier than with bigger countries. And I'm not even talking Russia or the US, but, say, the supposedly benign and enlightened folks in the UK. First there was the anti-child porn filter, that wasn't to be used for anything else, honest. Then there's that every internet connection is now to be filtered by default for the children's well-being and safety from porn; you have to ring up and admit you're a pervert and prove your identity to "opt-in to porn" (notice dishonest wordgame tactic, that "opt-in" is in the law itself). Let's take the logging and snooping by GCHQ on behalf of the NSA as a given and move on. For next up: The rightsholders mafia have figured out that a few simple lawsuits can make ISPs filter their client's internet connections on their behalf, too.

This sort of thing would be that much easier with an electronic identity card. Staying with the example, the UK already had identity cards, due to world war two, and only got rid of them in the fifties. During that time, the number of "functions" associated with the card rose from three (3) to thirty-five (35). That's quite a bit of function creep, well before the computer became mainstream.

There are many more examples. A canonical example would be the 100 flowers campaign. But now with the internet and ubiquitous electronic surveillance and handy dandy electronic identity cards attached. I don't think I want to live in such a country.

"It could never happen here" is not a valid excuse, even if you can prove that to be true in all cases in your country. So simply rolling out electronic identity cards is not something I want to happen. Exactly because they're so easy to use, they are a direct threat to my privacy.

The fix, by the by, is not to make them hard to use. It's to figure out how to make zero-knowledge identification work, to support multiple identities in a sensible way, and so on. Because we do need electronic identities, but the standard translation of one state issued identity per person is no longer good enough. Hasn't been for a while. Just count the number of times you've used a throwaway email address.

So if Estonia wants to keep on being a leader in this field, they will have to learn how to do this.

Not give information out. Keep it to yourself. With or without technological aid.

The individual trying this out either has to lie a lot (give false information) or risk standing out. That is, in the current environment.

To make this possible we need our systems (in the broadest sense of the word, so a government keeping records is a "system") to change the working assumptions. For many things you still "need" to give your name when in fact there is no need intrinsic to the function, only convenience, usually for somebody else, like law enforcement. This "convenience" carries risks itself, so it is long term all around better to get rid of it.

How you'd do this? Well, change the assumptions, change the laws, change how we organise things. Only after that does technology come into play.

And that technology? Authentication systems that aren't inevitably tied to just one possible identity per person and certainly not systems depending on some selection out of a small number of possible passwords per person with no redress possible, and also not systems that depend on a limited subset of "identity providers", reducing everyone else in the system to second class citizens.

Come up with designs that address those, and more shortcomings, that empower instead of subjugate. You might even consider deploying DRM around packed-up identity information, giving control back to the owner. Better yet, don't give the information away at all, for example using zero knowledge proofs. There are plenty of tricks ("technologies") and we are employing far too few of them.

Even the simple act of not requiring everyone to use the same database key for completely unrelated databases is, so far, too hard, and that needs to change. I could go on, but this ought to suffice for now.

While there is no single silver bullet, there is a clear general direction how we need to change our current systems, how we need to change our very thoughts and assumptions to keep a tenable society. Notice that everything so far governments and corporations have produced and are producing, fail at the very first of assumptions. A good case in point is "NSTIC", who were warned of these issues yet, as is evident in the design, chose to ignore the warnings.

Possibly, but then within the confines of a corporatist view, where a few centralised "identity providers" essentially own everybody else's identity and can do things others cannot, making everybody else second class citizens within the system. At least NSTIC was warned about this, but apparently nobody saw fit to heed the warning. Because, large corporate or (possibly and) governmental organisations owning other people's identities, eh, those in power just say they're "trusted" and thus they are. Reality? What's that?

So if your credit rating is shot...? Perfectly alright, just make sure you always have perfect credit, citizen. And it doesn't stop there, of course.

What mathematical proofs do they have to back up that rule? I won't settle for anything else, sorry. And even so, it won't be enough; it's just the beginning.

Within the limits of their understanding and their influence filtered through the rules of the procurement process. Which both isn't very much at all, for various reasons. The old lowest bidder and all that, but it goes beyond that, far beyond.

Simpler, yes. Desirable, no. It easily means that everything you do in any context is now easily linked. A state-mandated and -enforced real name policy. This is problematic for the same reasons that facebook or google forcing this on everyone is problematic. There are serious privacy problems with this.

For example, simply knowing what key a message is encrypted to --and this is generally listed on the outside of a message and thus public-- means that you can do traffic analysis. And so you know which parties are talking to which other parties. Someone getting a lot of messages from the taxman or the state-run fine collector means what, do you think? Or maybe a bank you're trying to get a loan from saw your message stream and now knows that you're also talking to a few other banks, or repo men, or what-have-you. Hmmm.... So even with confidentiality of the contents, you're still leaking information.

As such, this sort of card is only half the solution, especially since the state mandates that you have to use it, and it is so easy. What we really need is a single system that would support a single card (or multiple cards, if you'd like) with multiple identities.

I don't strictly mean birth certificate-backed identities, but at least so that you can separate out the loyalty cards and bus passes so that they can sit on the same card yet not tattle on each other. Because each such a card is an "identity" too, carrying a history, and I for one do not want them to be state-enforced on the same identity. In fact, this is the same reason why companies cannot be allowed to gather SSNs without clear law-prescribed purpose, and curiously, that is enshrined in law. Bit of an oversight that this is not.

No, simply saying "you can't mix that information!" is not enough, because it's unenforcable. You need a system where the holder of the identities can control who gets to see what. If the card doesn't support that, it is deficient, and a danger to its holder.

The problem with encryption is that it is bothesome, cumbersome, easily broken or circumvented by silly goofs and oversights, and generally impedes communication. The great enabling power of the internet is that it lets anybody talk to anybody. Encryption is not a good fit for that model.

Another approach would be global mesh routing, you know, mesh together every AP on the planet and hope no spots get left out. But mesh routing, while a nice idea, has scale problems, and we'll probably start to miss the really fat backbone pipes in a hurry.

The appropriate approach here is "government-technical", as in international law.

We have to get governments to agree to keep their hands off of the data that isn't theirs and they don't need for law enforcement and thus is obtained using a warrant issued for a specific investigation. To make this stick people must understand that data collected "just in case" is a liability for everyone involved and thus that not gathering data, while hard, is the right thing to do. Too bad it's hard to enforce. There'll always be some government transgressing, instituting star chambers, and so on.

It may be easier to get governments to agree to keep their hands off of the parts of the internet that aren't theirs. This probably implies some sort of intergovernmental oversight. But I wouldn't pick the ITU, nor the UN in general. They're too much clubs for governments, as if they knew what was good for the people. They clearly don't. Not even the USA, oh whooshing irony. So ICANN is out too, since it is really an US government subsidiary, regardless of what the both of them claim.

Do note that the USA clearly, literally claimed to be the only one country worthy of safeguarding the internet against wrongdoing governments, only to be shown a pathological liar about such things.

Since we cannot trust any one existing government nor any of the existing bodies, the internet will probably have to become its own country. Including datacentres that no longer stand in the country where they're built, but are now in "internet country", and thus entering the datacentre means crossing an international border. With extradition treaties and everything, but so that not one state can impose its law on all of the internet, as, say, Kentucky and iirc Utah did not too long ago.

The effects needed here are that both you can't be held answerable to the laws in any random country other than the one you're in (or do business with, or have some other clear relationship with), regardless of where the hosts involved physically are hosted, and that being held answerable to the laws of your own country (or do business with) becomes easier.

That, or we could try and get a benevolent global, planetary, government, but literally everyone with any shot at that has so far blown it, to the point that I wouldn't trust anybody else claiming to be that good either. So a separate country for the internet it will have to be. It is the simpler solution.

We're full of "universal" rights and whatnot... but fail to live up to them. Or rather, our politicians. The bureaucrats... play their little games. Or not so little, as the case may be.

If we don't want them to run rampant, we as the world's peoples need to take a stance. Do we want ubiquitous surveillance? Then do nothing. Do we want to have something of a private live left? Well, there's work to do. And some very unpalatable questions to find suitable answers to.

Our technology is so powerful that "because we can" is no longer a valid reason. We must choose what we want our technology to do. And to choose, we must understand the consequences of what our technology can do, and what it means to willingly forego some or all of the things it might have done. In extreme cases you can even portray this as trading saved lives, caught terrorists, convicted child pornographers, agains having some privacy left.

And so we must come up with answers to questions like, how many lives is privacy for all worth? How many abducted little girls may be allowed to die for not having to justify every step you take? Because, again, that is how the snoopers will portray it. And so we must answer, or find more reasonable ways to frame the same question. That, or lose the fight before it started. In a sense, we already lost while we were ignorant and we must now claw back what was once rightfully ours. From the jaws of those who claim to protect us (from privacy and liberty, but I digress). How much is it worth to you?

It does, actually: "Microsoft[R] SQL Server[R]"

And yes, they often do co-opt many terms and do that deliberately. In this, case, though, they still did but not to that extent--that's just the lusers talking. They aimed for that, of course, but "SQL" is not quite entirely the proper name of the product.

If it was sarcasm then the original question was a troll (and the question about SQL secretly about redmond's "sql server" offering only). Either way, it certainly was ment to be anvilicious. Some audiences need delivery that way.

The possibility didn't change the points about SQL and email from principles, so I happily bit.

It does, and the reason why is already in my previous post: It's a bad start to learn running email with. The question wasn't about running the software, it was about getting started, about learning to run it.

So learn this email thing properly first, then learn to tame exchange. It's not even much work, and certainly less than having to find out down the road, the hard way, your learned habits are bad ones, unlearning them, and re-learning better habits. It's about getting in the right frame of mind before filling it in with brand-specific experience. Might as well do it properly right away.

Beyond that, experienced admins (ie. a bit more capable than "operator" aka tape monkey) should be able not only to run multiple types and brands of systems, but also advise companies as to what are proper choices, in terms of both functionality to the user ("use") and administration ("maintenance").

Exchange is notorious for offering functionality that doesn't translate to the rest of the world (eg. "un-send"), among other tricks, while being high on maintenance and resource requirements. That is, there are opportunities for better service delivery and lower costs. But you won't be able to offer them if that one program is all you know.

That is another reason not to get hung up on one vendor's offerings, and for that you need interop. So start with software that does interop well, not with software whose vendor has a long, long track record of sabotaging interop in myriads of ways. Once you know how to do it properly, taming the improper stuff also becomes a lot easier.

Nowhere did I say to tell potential employers at the interview that they ought to be doing things differently. That doesn't work, of course. But if the employer is any good as an employer, you'll stick around for a while.

And then you can prove time and again that their decision to hire you was the right one (and get raises, if played right) if you can offer more than "exchange monkey"-type skills; if you can tell them how to get the same or more functionality out of less cost and resources. But to do that you need to do better than stick at "this one application"-level. It's a poor comfort zone to be in.

Might as well lay the groundwork now, even if the payoff is way in the future. We're talking building careers here. That's a multi-decade view.

Start at the beginning. Too many SQL users (including developers!) haven't a clue how to properly use it. As a DBA, you'll be called upon to provide that, among other things. So start with the theory and practice of SQL. Especially since it actually is founded upon fairly solid theory, meaning that if you know the theory the practice suddenly becomes a lot smoother. The rest will follow from that.

See db-class.org for a MOOC intro. If you've worked your way through that you'll know where to start looking for learning about the DBA-type things you'll need to do: Schemata, indices, query tuning, and then the subtler tuning like moving tables and indices around on disk or solid state or in-memory or what-have-you. And the basic knowledge will be useful any time a user asks for your DBA-hatted help.

As to exchange, it's crap, and you'll be better off knowing less about its internals. It's hairy and quirky and apt to eat your mail. In fact, it's not even a proper mail server: It's a suitable server for outlook, just as outlook is not a proper email client, but a suitable client to exchange. The combination means a lot of interop trouble that could've easily been avoided.

Since you'll be called upon to make it play ("nicely" is not in the books) with the rest of the world, again, start from principles. Learn how to set up an MTA, know how SMTP and IMAP work. Send yourself an email by telnet. Know what the various headers do. That MTA set up with matching IMAP server, don't have to be exchange at first, in fact it's better not to. Once you know how the rest of the world does it, you can learn how exchange fscks it all up, and how to keep the thing on a leash.

For bonus points, learn how to provide everything that exchange purports to provide ("collaboration" and calendaring and "syncing" and so on, as well as half-assed not-entirely-unlike-email type "messaging") using open-source software. Get that down smoothly (there are several ways and alternatives available these days) and you have another selling point: Providing a better experience with less cost.

That was what you're looking for, right? Points to sell yourself with?

There's a strong "US vs. THEM" sentiment in law enforcement, facilitated by a decades-long trend of "militarising" the police, eg. SWAT teams. Originally specialised, now used for increasingly everything. The gun totery and body armour sure look impressive, but it has nothing to do with connecting with the community.

Find ways to get police forces of all sizes, local, state, and federal, to focus on policing again, not on playing supercop with the general populace as targets of convenience. Don't be afraid to get rid of a few entire agencies should that prove necessary.