Drawbridge?
I'll be sure it's closed & the battlements are full of English Longbowmen to defend the castle from the MS barbarian hoarde. Thanks for the warning!
In March, when Microsoft announced plans to release SQL Server for Linux, Scott Guthrie, EVP of Microsoft's cloud and enterprise group, said, "This will enable SQL Server to deliver a consistent data platform across Windows Server and Linux, as well as on-premises and cloud." The release of the first public preview of SQL …
"SQL Server for Linux runs atop a Drawbridge Windows library OS – a user-mode NT kernel – within a secure container called a picoprocess that communicates with the host Linux operating system through the Drawbridge application binary interface."
Cool - so basically they are using Linux as a container / hypervisor. So presumably all the security and ease of use advantages of SQL Server and Windows - for instance Kerberos Delegation - will still work just fine? I guess probably it's slower though on Linux....
>Cool - ...
>I guess probably it's slower though on Linux....
Who needs performance or scalability (or even stability, this is beta as hell after all) in a database solution? This smells of checking boxes in marketing material (see we are cross platform, not locking you in wink wink) more than anything.
"Why do we care about desktop advantages on a server? "
Ease of use doesn't have to only be a desktop feature! It makes for a lower TCO via a lower cost of entry, lower training costs, users / DBAs prefer a simple life, etc, etc... However "ease of use" for SQL can also be via the remote management toolsets, not actually on the server...
Does this include a full version of PowerShell (which many remote admin tools rely on!) ? That would be a massive improvement on say BASH...
"So let's find a fancy new name so we can pretend to innovate!"
Hooooooold on, thar! [vague Quick Draw McGraw reference]
Let's step back about 2 meters and see what this REALLY means...
THIS means that MICROSOFT has a 'Wine-like' CONTAINER that could be used by *ANY* windows application maker to, *ahem*,
*QUICKLY*! *PORT*! *THEIR*! *WINDOWS*! *APPLICATION*! *FOR*! *LINUX*!!!
Which implies... that a LINUX PC could (theoretically) run *ANY*! *WINDOWS*! *APPLICATION*! if Micro-shaft would *BOTHER* *TO* *RELEASE* *THIS* the way they had a nice XP subsystem for Mac OSX a decade or so ago... remember?
Maybe Linus could get that built in to Linux. Killer app for Linux on the desktop, finally making it the year of Linux on the desktop (as well as losing the command lineand replacing it with a GUI for people that are too old, stupid and/or lazy to learn the command line - like me).
"Maybe Linus could get that built in to Linux."
Why?
What they've done is simply provide an library level emulator on top of the Linux system calls and libraries. A non-proprietary version of that has been about for years. It's called Wine.
"too old, stupid and/or lazy to learn the command line - like me"
I'll hazard a guess that I'm a good deal older than you. I've installed Linux for a number of even older relatives who never need to use the command line. As you seem to be admitting to being stupid I'd suggest that that lies in not realising that you don't need use it unless you choose to.
Which implies... that a LINUX PC could (theoretically) run *ANY*! *WINDOWS*! *APPLICATION*! if Micro-shaft would *BOTHER* *TO* *RELEASE* *THIS* the way they had a nice XP subsystem for Mac OSX a decade or so ago... remember?
Most Linux geeks would refuse to touch it. One of the biggest drives for switching to Linux (at least on the desktop/workstation side of things) is to get away from Microsoft. Sure, we've got Wine, but that mostly just gets used for games these days.
Wine is quite different to Drawbridge as it's not running an NT Kernel.
Useful for old Windows programs with no Linux alternative, and may run ones that won't work on Win7 / Win8 / Win10.
The only point to Windows was the legacy compatibility. They have badly broken it and also MS has emulated some APIs used by traditional "Forms" based GUIs in favour of GUIs written Direct3D APIs, which is crazy for ordinary non-media programs. Does MS think users only want video and games and force devs to use higher RAM resource APIs for "ordinary" applications? Mad.
Drawbridge is a proprietary way for MS to distribute to paying Linux users, it's not a good idea for users that want to run legacy applications.
We're talking about GUI vs command line, etc, but yesterday I had to use Powershell to get replication to work in a HyperV platform because the GUI wouldn't find the correct certificate for HTTPS authentication.
At least on Linux servers, you don't get a shock when the GUI doesn't work properly, because you don't expect to be using a gui full stop.
It also doesn't try to reboot itself once every couple of weeks unless you perform some low level registry hacks....although I believe they (eventually) hotfixed that.
Steven R
Obviate has two accepted meanings (listed in most dictionaries)
1. Remove (a need or difficulty)
2. Avoid or prevent (something undesirable):
So "obviates the need for" is not incorrect under meaning #2. Arguably redundant but then so is "PIN number" and "wipe that smile off your face". Zero redundancy doesn't necessarily make for good writing/journalism
I can't help wonder who their intended target audience is going to be. Because I can't imagine that there'd be a large market for this. When it comes to databases then you can use all the performance you can get (depending on the database of course). So layering it with virtualization seems like a lot of overhead to me. Especially when the Linux box itself is already running in some kind of virtual environment.
Maybe Azure?
Is it possible that Slurp is hearing through there back channels that many 'bloat server customers are planning to migrate to Linux? Relational databases behave very similarly (some differences in the SQL dialect and the DDL) that changing one for another is relatively straightforward. If Slurp wants to stay relevant, their products will probably need to run on other server OSes.
This post has been deleted by its author
> I can't help wonder who their intended target audience is going to be
Organizations that want 'free' but don't care about 'open-source'? SQL Server Express running on Linux means a proper database for no money. Postgres is lovely but if you have SQL Server skills in-house you'd probably prefer to use them.
Whether we can trust Microsoft to stay invested is another matter — I'd be very worried about being abandoned after a year and yet another change in strategy.
I do not think there would be much of a virtualisation overhead, since the technology does not virtualize a machine, only an OS. As you move up the abstraction layers, the optimization opportunities are more obvious. In other words, it is system calls which are virtualized now, not the CPU. For majority of Windows APIs there is a very simple relation to Linux system calls (especially if you control also the application code, i.e. SQL Server itself). This means a wrapper will add very little overhead. This also includes IO (at least with the most popular options, including asynchronous IO) which is the largest source of virtualization overhead and coincidentally also major source of database performance issues (next to CPU cost of running queries). Also, Microsoft is obviously aiming this as competition to Oracle on Linux, so they cannot really afford large overhead.
For the most part, if you follow a traditional technologist POV, the entire idea is entirely preposterous. This smells like one of M$'s latest forays into a growth area because their revenue is not meeting growth expectations, and may even be on the decline.
Linux has always been the database platform of choice due to it's lack of fat layered abstractions that require code that should execute in 1 CPU instruction that instead requires 50 instructions.
Taking this approach with porting to Linux is absurd, and like M$'s feeble efforts to enter into the healthcare EHR market (which was yet another M$ miserable failure) this looks like yet another desperate attempt to right the sinking ship.
First of all, if I have a SQL Server db and need to increase my performance without spending ridiculous $$ on hardware - which will only provide minor performance gains on the sluggish windoze server platform - I have a nearly identical database management system that already affords near seamless migration to a platform that is superior in every way for database performance:
http://go.sap.com/product/data-mgmt/sybase-ase.html
For you yonkers and M$ groupies out there, SQL Server is a hacked up, dumbed down, platform-neutered version of Sybase, which is now owned by SAP. Sybase has been around since 1987 and cut it's teeth on Unix platforms. When M$ decided to enter the DB space - a totally new space for them - they had absolutely bupkus to offer the marketplace. So they did what big, fat, incompetent, arrogant companies do, they buy - or in this case license - a superior product that already exists and rebrand it.
https://en.wikipedia.org/wiki/Sybase
I can take my SQL Server database TODAY, and migrate it to Sybase with minor modification, and I'm up and running on a platform that boasts superior memory management, vastly superior filesystem performance options, and dramatically less code bloat / platform layered abstraction. Not to mention a DB platform that didn't get frozen in it's development in the early '90's, but rather a db that has excelled in nearly every area over it's dumbed-down cousin.
The only reason that this might sell is because most M$ customers are ignorant groupies who don't understand the options available to them and are religious about their platform and language of choice - because they don't know any better. M$ operates on the crack cocaine principle - once you're doped up and hooked on the drug - you will eventually become too stupid to even bother to validate whether or not the crap that I'm selling you is good for your business or not. You are simply looking for your next fix, and are addicted to the label.
While SQL Server - in all fairness - is somewhat competitive with other DB's out there, I have numerous choices that already run on a number of platforms that boast superior performance. So this is a total non-starter...
I was the loan Sybase DBA / developer for a 23 / 6 trading firm for a good half-dozen years or so. Until ASE 15. At that point I realized their product roadmap had gone so far in the wrong direction that they were destined to have their marketshare sink to where the mindshare was (nowhere). They were making themselves more like Oracle than like MS. Sybase always provided decent performance and great reliability straight out of the box, with low licensing and very low admin costs relative to Oracle, which always seem to need two DBA's, a SysAdmin, and a storage guy just to install it; MS was the opposite; I know MS shops that don't even have a full-time DBA on speed-dial; not saying it's a good thing, but there you have it. Further, since about SQL-Server 2005 MS started introducing cutting edge features way ahead of Sybase. I'd have switched to MS long ago if only it ran on an enterprise grade OS. Like Linux.
Having worked in Unix, Novell, and M$ shops for 24 years I had the opportunity to learn a lot about the differences between the OS's and the products that ran on them.
I hear you concerning a great company taking a great product in the wrong direction; I've seen this with other products as well. While it is frustrating, it usually isn't worth jumping ship over.
As for those 'cutting edge features' that are supposedly 'way ahead of Sybase' I would be remiss if I didn't remind that cutting edge features or not, SS still runs on NTFS; Windows still uses the archaic, technologically ancient and thoroughly eclipsed page file; all applications have some portion of their memory paged out to disk, no matter how much physical RAM is available. This is why when I build Win servers and clients I always double-triple the memory requirement, create a large RAM disk, and create the only page file on the RAM disk; this allows me to work around - in the only way possible - these crude limitations that harken back to the late '80's. It's still not as fast as the UNIX memory models, but it's better than the stock Win approach.
So cutting edge features aside, due to the fact that Sybase has always been UNIX aware, it can leverage hardware resources that aren't even available to the Windows world, such as XFS and JFS for speedy large database file access. So those "cutting edge features" are more than offset by the platform performance potential alone that is natively available to Sybase.
"Windows still uses the archaic, technologically ancient and thoroughly eclipsed page file"
Just like a Linux uses swap file you mean?
"This is why when I build Win servers and clients I always double-triple the memory requirement, create a large RAM disk, and create the only page file on the RAM disk; this allows me to work around - in the only way possible"
Or you could simply disable paging to disk....
Linux doesn't use a swap file.
Linux uses a swap partition. But the normal 'nix algorithm (varies from distro to distro) typically will not swap out anything until the physical RAM is in danger of being completely used up. Windoze, on the other hand, swaps out memory to disk when there is no need to swap it out; as soon as you run one program part of that program's memory will be swapped to disk.
Windoze without a page file works about as well as a car without brakes. Run Windoze without a page file and as soon as Windoze runs out of RAM - and sometimes sooner - it will crash.
Take some time to learn not only how Windoze works, but how other OS'es work as well. You might be suprised at what you find.
Sybase always provided decent performance and great reliability straight out of the box, with low licensing and very low admin costs relative to Oracle, which always seem to need two DBA's, a SysAdmin, and a storage guy just to install it;
Amd there in lies (one of) the rub. Sybase completely lost its way with licensing and thre away the fairly reasonable licensing in favour ridiculously inflated licensing costs in some aspiration of imitating Oracle I suppose.
"Organizations that want 'free' but don't care about 'open-source'? SQL Server Express running on Linux means a proper database for no money"
This only makes sense if SQL Server is the only thing you recognise as a "proper database". Some of us not only recognise other "proper databases"* but regard SQL Server as a Johnny come lately.
*Database engine or database server to be correct. Databases are just the collections of data that the engines manage.
""Organizations that want 'free' but don't care about 'open-source'? SQL Server Express running on Linux means a proper database for no money""
That's probably where this is headed - let devs that like trendy OSS stuff play with this to develop / test on, but when you need to scale up / care about security / want production grade clustering, you can uplift to Windows Server....
care about security ...windoze...
Would be cool if El Reg would publish the shill's IP addresses. I think Vogon would very quickly change the tune on MS and security. Or disappear forever under the load of attacks from the rest of us.
(Although we'll probably find out that while TV is paid to promote MS "security" [cough] they cannot pay enough for TV to use MS's shiteware!)
[says he who is currently building a Win7 box and is posting from it during day 2 of the ordeal]
"That's probably where this is headed - let devs that like trendy OSS stuff play with this to develop / test on, but when you need to scale up..."
...then you keep it on 'nix. Over the last few years we've migrated a shedload of server stuff to CentOS, and this just adds yet another service that can now be migrated.
It's saved us a bucketload in costs, not just up front but it's also no less reliable reliable while being easier to manage, and doesn't involve the added cost of having to actually manage licenses which is non-trivial (esp. with virtualisation in the mix).
In fact the only thing left on Windows Server is AD plus a few legacy corp apps including SQL Server. Most desktops are too obviously thanks to the likes Office, but now that the board has acknowledged to the very real cost savings we've managed on the servers without loss of reliability, they will be the next to be reviewed.
There's some software which pretty much insists on SQL Server (looking at you Sage), but if you prefer linux on all your servers, this might be the solution.
(Although any company that insists on SQL Server will probably not support their product on SQL Server for linux for years anyway)
A couple of years back my place of work would have been a perfect example - server-wise a Linux shop (no licensing minefield!), but some commercial applications require SQL server and there is no sensible/affordable alternative.
In the end we hosted a Windows VM on one of the Linux VM hosts, but it was always a security worry. If we had found an equivalent functionality/equivalent price application that directly supported MySQL or Postgres we would have certainly gone for that - this new approach from MS is a useful solution to the problem we faced.
They don't have an application to convert a Linux admin to a Windows admin.
Probably because it would see little use.
They have, however, spent a great deal of time and money working on converting Windows users and admins to Linux ones.. To list a few : GWX nagware, Win 10, Win 8& 8.1, the constant breaking of working systems with untested "updates", their removing software that people paid for because MS don't like it, their utter hatred of their customers, their lack of decent security
So what's the practical overhead of this, as, the memory sandboxing does sound like a useful security step over running it on a windows box (which I'm trying to work out if that's ironic).
I know I don't use my SQL server to anywhere near it's limits on the VM it's running on now, if I could port the underlying VM to linux without the gripes I got from users when I suggested switching to MySQL I can at least save on the licence cost of the host VM.
(we're a relatively small business, so appreciate our use case differs from most of the market)