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.

Note that multi-party systems can work fine elsewhere. So even though this'll get plenty of knee-jerk reactions for reasons that are inscrutable to me, I'd suggest direct representational voting, or some other way to stop gerrymandering being possible, or useful.

The system was indubitably pretty neat back when, but hasn't scaled well. Take the ingredient principles and build something that fits the current (and future, for say 50..100 years--investigating your voting system every century for effectiveness and possible revision isn't bad) situation better. In general, some system that doesn't happen to have a two-party-only implicit system property.

Do away with "we don't spam because we're politicians"-exemptions, like for robocalls. Find a way to stop lobbying being so lucrative; a focus back on the voter would be nice. Might as well try and dismantle the military^Wsecurity-industrial complex, but that'd be a good thing too.

I do believe that when you produce any digital content, you should have the right to control the means of distribution.

Why? What makes "digital" so different from, oh, music, books, anything with copyright on it, that suddenly the first sale doctrine wouldn't apply?

I myself wrote free software once, and when I found out somebody was selling it on ebay and elsewhere, and expecting me to support it, I was pretty well pissed off and went out of my way to make sure that it would only be distributed by the means I chose.

Yes, that is more than a little annoying, but the fix isn't DRM. It's enforcement of your copyrights. That is in fact how the GPL works. If that software was public domain (or similarly loosely licenced) then that includes allowing reselling, though the "NO EXPRESS OR IMPLIED WARRANTY OF ANY KIND" disclaimers are the usual CYA against having to support it. Some people will still be unreasonable about it, of course, but some people will be unreasonable in any case.

There is no requirement whatsoever that enforcing your copyrights includes DRM. DRM doesn't guarantee lack of false positives or preclude rampant DMCA abuse either, far from it. So you'll have to think this one through again, sorry.

By the network effect, entrenchment, that sort of thing.

The practical fix? Make the internet be its own country, and put all infrastructure (especially the DNS) and international servers in it for legal purposes. Then every country needs only make "internet extradition" treaties with "the internet", not with every other country possible. That is also the only way to ensure cencorship as well as warrantless wiretapping stays within bounds.

You can't prevent all damage, but you can contain it, and route around it.

The "analysts" are, too. On top of that, phones are still a "platform" to deliver "an experience" ment only to please you insofar it lets the carrier "own" you. Thus the walled gardens. Thus the NFC push, with a secure element in your phone that isn't owned by you. It owns you, instead.

In that context, any and all extra sensors is more ways to spy on you. That is all.

What I'd like? As a phone, a device that lets me connect with the rest of the world. As a computing device something that lets me run my own code and have full control over every aspect of the hardware. Yes, down to the GSM stack, and it's possible. Combining, a device that shows me the available ways of communication and lets me take full advantage of every one in reach, any way I'd like. Enhanced by my own apps.

This is something quite different than the "seamless integrated experience" that apple does so well -- we already have that, thank you. Now for a raw power in my hands communication tool.

Plus, robust hardware that actually performs above and beyond "tickbox level" that fails to deliver when pushed (looking at you, "enterprise class" nokia phones). Good battery life. In that context, linux is and always be too heavy, simply because it contains too much code and never was designed for low-power use. You can get a long way, sure, but never quite as far as, say, psion got (before nokia fucked it up under the symbian moniker).

And then there's this: Privacy. Every single phone fails on this point in at least one way. Pity we'd need different protocols to really make it happen (ought to be part of 5G, so EU, if you're listening, make it a requirement for the subsidies you're tossing the phone industry for making 5G happen). Smartphones fail on this in more than one way, and there's really no way to fix that in the current models, so better models are needed. As well as more due dilligence. Too bad we'll only get a little fake bit of the latter, no more.

But for starters, I'll take a dual-sim (micro sim, no smaller) candybar no thicker than a centimetre, fits in trouser pocket, with a basic camera, 3.5mm jack, micro sd, wifi, voip, tethering, modem with working fax support (that really is but a SMOP, but occasionally oh so useful), basic packet data support, voice encryption, at least a week of stand-by, and cyanogenmod support or equivalent under some other OS. This obviously fits the models of exactly nobody who has any influence on what sort of phones will become available.

And so the notion of "innovation" among phones will remain rather vapid, as usual and by now entirely expected.

Back in the day you had sewer gas destructor lamps. Seems those would work with leaked gas too. Plus, add some sensors and you can figure out where the gas is likely leaking, so you can do something about it.

Even so, lax maintenance is nothing new. I recall reading about a certain bollard in Amsterdam that had sported a nice little flame for ages. Until someone realised it must be from a gas leak. Then it got fixed in a panic.

I'm all for reducing^Wgetting rid of protectionist subsidies. Problem is, of course, that but a few, even just one large enough party has to start and everyone follows suit for fear of being left bereft of local producers because they weren't subsidised enough.

Also, not happy with using things we could be eating to generate energy. Corn is just silly, inasmuch that ethanol-for-energy from it being economic illustrates your point. Purpose-picked and -bred crops are better, but still not ideal.

Much rather I'd try, oh, taking PV or some other collection mechanism to a desert, and somehow use it to provide shade and moisture retention for crops that couldn't otherwise grow there, as well as for its energy collection properties.

Tangentially related is the practice of getting fertiliser from faraway, using it locally, then not transporting the waste that normally would be eventually turned into new fertiliser back. That is a problem that ultimately results in exhausted land and then into more destruction of rainforest for more farmland to exhaust. Not the only factor, but still.

If we'd take out all subsidies, including indirect ones (say on fuel), we might find that prices change but not necessarily up the cost of living. The subsidies are paid for by taxpayers, so the net effect over the total population is going to be a small drop due to less overhead (ideally), even if individual food prices will be higher. What it'd do for the individual? Maybe it'll end up promoting a change in lifestyle, reducing obesity, who knows?

Servers are still designed like PCs.

Servers didn't use to be beefed-up desktops, no "still" about it. That they are now has to do with cheap desktop ubiquity and wanting to use desktop emulator software to underpin "servers". In short, middle management stupidity.

But that sort of thing fits well with TFA, where they say "look ma, no OS!" when they do have software acting like that, only not calling it that. Put the achievement in perspective and it isn't nearly as ground breaking as implied. So the announcement is a bit pompous. Well, nothing new there either.

It's all a bit bass ackwards, but then so is the whole peecee paradigm. The whole virtualisation thing has been with us for ages, in many guises. This is but yet another. Likewise, single-language app boxen. Lisp machine, anyone? Only this time with erlang.

On another note, rethinking how we organise monitors, supervisors, hypervisors, hardware drivers, and all that, and how they interact with userland, isn't a bad idea. This here idea is a valid approach, but by no means the only one.

Add a bittering agent to make the thing taste bad. It's not that otherwise it won't work, just that if it tastes foul enough (but not too foul) it'll work better.

In a sense there really should be a nicely packaged version with the usual warning sheet and everything. Possibly even a "low dosage" variant you can get at the druggist without prescription.

I'd start a venture producing them (already have a nice product name) if not for the heaps of regulatory red tape and the trouble with the required testing. Before I know it I'd get sued by animal welfare groups for needless animal cruelty or something.