That's a really nice piece of hardware. I've used MacBook Airs since 2010, but the Surface 3 looks to be strictly dominating in the hardware department.
Unfortunately, I don't think Microsoft will convert many OS X devs unless they make some changes to their software. One of the advantages of OS X is that it's a Unix, and lots of Unix software runs on it. It's not hard to compile tools such as nmap, Vim, or steam locomotive.
It would be very interesting if Microsoft made Windows a Unix. They could bundle bash or zsh, add the typical BSD tools, and (most importantly) build a cc front-end for the Visual Studio compiler. They'd also have to ship a libc of their own. To save effort, they could base it on BSD's libc. It'd be like Cygwin, but installed by default and officially supported and maintained.
With such a set-up, you'd be able to run your unix tools alongside Adobe CS and Outlook. You wouldn't have to worry about driver support, since Microsoft made the hardware and the OS (just like Apple). The only thing missing would be the ability to dual-boot OS X (to test on Safari or other OS X stuff).
In my experience Cygwin works better for the "compile software targeted mostly at Linux users" use case, but Microsoft definitely pursued the "make Windows a Unix" approach. Sadly Interix saw limited adoption (probably due to pricing) and has been discontinued, so we're left with the user-space emulation approaches (like Cygwin).
They should really just buy cygwin and make it the default shell keeping powershell as optional. It's time for MS to acknowledge they need to catch up and be a little bit more interoperable with power users from other oses.
cygiwn is one of the first thing i install when I bring up a new windows box.
Powershell ties in much, much better to the Windows infrastructure than any POSIX-like shell does. Managing Windows revolves around managing long-running services, and sending off requests to them which return rich data objects. This is an entirely different problem set from managing processes and files.
Modifying Windows to be administrable through a POSIX shell would change what Windows fundamentally is. I'm not sure that's a great idea.
Personally, I enjoy working with Powershell much more than I enjoy working with Linux in the traditional way (through a shell), and I currently don't personally own a Windows machine.
I don't think a shell is a very good interface for direct use; it's entirely non-discoverable past man pages. It's a great interface for developing reusable tools, though. I strongly dislike having to use it directly, preferring to develop scripts that I can access from my text editor.
As a developer, I think what you want from a shell is different from what a Windows admin wants from their shell. The Windows admin wants to manage the services they have installed; the developer wants to manage whatever files they have in their source tree. I don't think it's particularly terrible that Windows should be bundled with a tool for administrating Windows, rather than a tool for developing new software.
1) I can install an unpopular Linux distro onto it (NO VM!).
2) I won't get serious issues on Linux, due to no drivers being found compatible, overheating, hybrid-gpu switching problems, touchscreen issues, jumping stylus, battery dead in <3h
3) UEFI isn't causing as much trouble, as I've heard.
4) The keyboard is much better than the crappy colored plastic it looks like. I want a high quality keyboard with backlight. I would pay $200 extra for that.
5) It has HDMI, USB3 and a way to increase the internal storage and ram.
@smrtinsert
Should, would, could. But they didn't, for about two centuries, sorry シ
There is so much hope in your writing, hope that Microsoft recognizes where it erred and where it did it right. Alas, there might be no such plan, because they haven't found a way to directly capitalize on that yet, or political/strategical/management reasons.
I don't have any prejudices against Windows, OSX, Linux, BSD and alternative OS users, but I like all of them. What makes me and probably others turn off the ears are hardcore evangelists of any kind just as well as fanboys/fangirls. This is not directed to you, you're ok check ✊ . I just want to say that, there are such people whom you can innocently ask, why they've installed Windows onto their Mac (for example) and all you get is arrogance and hatred plus a bunch of prejudices on how one can question the superiority of windows. On another case I talked with a Windows Phone developer and she was such a hard knock evangelist, I was kinda feeling attacked, just because I asked how she plans on integrating with the back-end software we've developed to deploy the final app to various app stores.
Re: 1, 2, 3: Those are Linux problems, not Surface ones. There are types of hardware that Linux is just poor at supporting. It's up to Linux devs and the component manufacturers to fix that problem, not Microsoft.
I found it pretty easy to put Linux on my Surface Pro 2. The problem is that once it's on there, it kind of sucks. Poor hardware support, extremely poor touchscreen UI.
> Piping programs into each other is okay, but once you start bundling it's all up in the air.
How does bundling mean combining it into an _executable_ file? Sure, this could be the case for an installer, but that one could also just download/copy the files.
In common usage (I've never heard it any other way in 24 years of software dev) "included in the same executable" means either combining the source files, or linking object files, or similar. "Bundling" means shipping together, packaging together and never, ever has meant "in the same executable". You do know that .zips .gz and other packages aren't "executable" in the sense used by the GPL, right?
The example of an installer can't be more unambiguous. I quote "No. The installer and the files it installs are separate works. As a result, the terms of the GPL do not apply to the installation software." No. Full-stop. GPL does not apply.
If an installer of GPL software doesn't have to be GPL then certainly unrelated software which happens to come in same disk/download doesn't have to be.
Yeah, njharman describes bundling as I understand it as a programmer. What did you mean by "bundling"? If it was "Packaging two programs in the same archive." or "Using Cygwin Bash to kick off our proprietary program.", then those activities are unambiguously permitted.
I'm rooting for MS. My (not so serious) test for windows is simple: the day I can resize dos command prompt as easily as terminal windows on linux/osx is the day Microsoft I need to seriously consider going back to windows :)
I think you're going to live forever disappointed. The command prompt shell is one of those programs that just doesn't get updated and/or any new features. Like notepad.exe, there are so many easy things they could do to make it actually _useful_, but won't.
Not disagreeing, but I suspect notepad.exe is the way it is for a reason - it's the Windows equivalent of vi, the thing you use to try to recover when everything else is falling to pieces. As such, it doesn't and shouldn't have dependencies on anything that isn't absolutely essential.
I believe Task Manager eschews the common control library and reimplements a lot of UI stuff itself. Same reason.
You don't really need to pull in external deps to improve notepad.exe; nearly all of the low-hanging fruit would be a few lines of code in that application itself. Even busybox's vi implementation is a more capable editor, and it's one short C file (with a handful of trivial deps on the rest of busybox for shit like the allocator and random string functions.)
I still can't believe that a hung program means the Task Manager can hang as well. I don't know how many times I've had a game freeze and had to wait on the Task Manager. Ctrl+alt+del brings up the "lock, log off, task manager" screen pretty quick, then Task Manager doesn't load until I go make and finish eating dinner.
Since that shortcut was added, that's almost always how I launch the Task Manager. Recently however, I read that Ctrl-Shift-ESC (CSE) doesn't launch the Task Manager in the same way that Ctrl-Alt-Del (CAD) will.
I went looking for the source but I only found this blog post from Raymond Chen [1]. Based on that discussion, it looks like winlogon.exe is responsible for launching the Task Manager both ways, so perhaps that more recent discussion was incorrect.
Does it still take minutes to load, though? My problem has never been the difficulty in launching Task Manager, it's been with getting task manager to respond in any amount of hurry.
I just hit CTL+SHIFT+ESC and Task Manager was there instantaneously. If things have gone so screwy that you really need Task Manager, then yeah, it will probably be slow.
I know you're not being serious, but there are some other terminal apps that are better than the basic DOS prompt. Check out ConEmu, for example.
Now, once you've got ConEmu or something like it that will resize nicely and do other things, you'll still be stuck on the crappy DOS-style prompt though. :)
I feel similarly, and seriously. It's not so much just the usability of the command prompt, but that it would be a symbol of a change in priorities towards adding functionality for developers, and welcoming non-Windows technical audiences.
If I'm using a non-built-in terminal, and a non-built-in Unix compatibility layer, why am I using Windows?
See, this is why I like Linux and OS X. The built-in Terminal is practical. The built-in text editor (well, at least on Linux) is practical. On Windows, I have to replace both from the get-go to get anything done.
I'm not, in that at work I use a Mac. I write Java server code for web servers and batch data-analysis, deployed on Linux boxes. A significant portion of my time is spent either ssh'ed into a Linux machine, or using the various Unix utilities as well as git and mvn in the terminal.
My point, perhaps poorly stated, was this: I prefer a terminal-heavy development environment because that is the most efficient way of interacting with remote servers for the work that I do. I can't consider using Windows without a sense that they've made it a priority to address my use cases and scenarios, and the single lowest hanging fruit possible in that regard is to spend half a dev team (2-3 devs) on modernizing the terminal to the point where when I'm at home and want to check something on a server, I use my Windows desktop instead of switching to my Mac laptop. Even better would be dedicating one or two dev teams to supporting a Unix environment natively, so Cygwin isn't necessary.
For what it's worth, I much prefer the Windows GUI to either Mac or Linux. I was a test developer at Microsoft for Windows 7 and part of 8, and I wrote this comment on my home PC running Win7. I would like to be able to use Windows for the UI and the familiarity I have with it, but those two things, a good terminal and a Unix-like environment, are requirements for my job. And I know from experience that this scenario is absolutely the furthest thing from the minds of the people working on Windows.
Most developers don't have a choice in the supported platforms of the product they work on. If your product targets Windows (and it will if the customers demand it), you don't have much choice!
Also checkout Cmder (http://bliker.github.io/cmder/) for a pre-customised ConEmu that bundles several useful UNIX commands. Plus ConEmu supports Quake-style dropdown that has radically improved my work-flow on Windows.
Also Powershell is pretty awesome if you take the time out to learn it.
This. ConEmu combined with cmd/msys/cygwin/powershell is as close to a proper unix terminal app one can get. I actually find ConEmu itself better than the corresponding Gnome/KDE/Xfce/OsX applications.
The thing is, if you actually look at how those programs work, they're still actually running cmd.exe and then wrapping that. This leads to all kinds of weirdness...sometimes resizes don't work quite right, color support is iffy and requires yet another wrapper, etc. It's better than nothing, but it's a FAR cry from something like konsole or even generic tabbed xterm.
Another is Git Bash (http://git-scm.com/downloads) which gives a reasonable terminal/shell on Windows including many of the standard utilities (e.g. ssh).
Is it as slow as cmd? I found that running `readelf -a` in cmd will take, say ~5 seconds while running the same command under Cygwin+PuTTY, the command completed in well under a second. The text output is just plain slow and to a baffling degree.
To this day, I don't understand why don't didn't have an intern or somebody fix that. They push powershell so hard, yet provide a horrible, horrible terminal to work in. Make it like putty. In fact, go find one of these makers of terminal software and just buy they out... Do something. Nobody takes their command line stuff seriously simply because the terminal is so god-awful.
Get Far Manager www.farmanager.com - you'll have the both the command-line and midnight-commander/norton-commander like file viewing/browsing copying tool. Press Ctrl+O to toggle between full-screen and showing the file bars. Maximize the windows as much as you want (it'll work). Make the shortcut to start Far Manager maximized.
There is even project to bring ConEmu + Far Manager, and there is even way to make Far Manager work with cygwin's bash (I have separate link for it).
Give it a try - it's zip-installable, and has real installer too. Lots of plugins (including zip browser, exe browsers, ftp/ssh/etc.)
I'm of the same opinion as paperwork. I can't speak for him/her, but for myself the reason is not that I can't get the software I need (Console2 and mintty suit me fine) but because the quality of the tools provided with the OS are indicative of the general level of polish (inside and out) of the OS as a whole.
If they haven't managed to fix some of the most basic and most user-visible flaws in the past decade or more, what other cruft is lurking in places users don't regularly see? Additionally, as a software professional myself I see a whole lot more of the ugliness under the hood than most users and it does nothing to suggest to me that my first impression was wrong.
Edited to add: I know you didn't actually disagree, and your suggestion is a good one. I felt it would be taken by many as a reason to discount the original opinion though, and wanted to emphasize what I feel to be the more important aspect of the original notion.
We can't always choose the hardware that we want, and we can't sometimes choose the software (OS) that we like.
At work I'm stuck with Windows, but at home use OSX & croutonized debianized chromebooks.
In my regular Windows toolbox are: Far manager, cygwin (full install), SysInternals, NirTools, Windows 8 SDK/DDK, emacs-win, but haven't time to get around and learn Powershell...
I actually find PuTTY to be horribly frustrating to work with, compared to a proper terminal emulator on OS X or Linux. Part of that is just Windows (when the window closes it's gone), part of it is that it's really just an SSH command (no local terminal, no easy SCP), part of it is the cumbersome UX (make a bunch of changes to the connection and then hit 'go'; oh wait, you didn't save the changes first? crap).
I do agree with the core of your point though; an actual terminal with actual commands that actually work well would be great.
Windows Powershell is actually really fascinating from one point of view though: the idea that instead of passing raw (inconsistently formatted) ASCII/Unicode data between pipes, the data is actually presented in terms of a data structure; thus you can easily say 'sort by the third column descending' or 'show every second record'. A significant amount of my bash scripting on-the-fly tends to be chaining several commands together to munge output data solely for the purpose of letting the next command parse it properly. Powershell, in some ways, takes care of this.
In 2014, PuTTY still makes you set your whole window to a complete Unicode font (usually buggy and weird-looking) to avoid international text showing entirely blank. Surely even Windows has better text API than that?
He/she is referring to dynamically adjusting the characters size (its line wrap) when resizing the window. You can even resize the command prompt to fullscreen but the lines wrap to 105 characters by default.
Because some of us have to deal with hundreds/thousands of servers. Lots of Windows boxes without Chef/Puppet bootstrapping them is a miserable experience. I don't know how many times I've disabled IEESC and made cmd quickedit enabled in my life just to be able to use the box (prior to doing it via bootstrapping).
Let me enlighten you then. Just create a shortcut to the cmd prompt, change the settings in the shortcut and keep a copy of that shortcut. The seetings for teh command prompt are saved in the shortcut. Now you just have to go around with it on your USB key and double-click on it to have a command-prompt with all your settings already done.
I wish all other windows were this easy to resize. I could simply have an array of shortcuts for all the different browser window sizes I might want. It's a much better system, really. Thank you later? I'm thanking you right now! Thank you.
Long, long ago, I wanted a way to launch arbitrary numbers of CMD.EXE windows with arbitrarily-chosen foreground and background colors. The standard settings only let you store a finite number of color entries (something like 16) to choose from. However, the registry key it finds the settings in is based on the executable name, so if you make a copy of cmd.exe called cmdb.exe and run it, you have N more slots of colors to choose from. So I wrote a little hack that took --fgcolor rrggbb --bgcolor rrggbb values and then made a hard link to cmd.exe in the temp directory called something like cmd_rrggbb_rrggbb.exe, set up the appropriate registry keys, and then invoked it with whatever other args you provided. Subsequent invocations with the same args would find the temp executable and reuse it. It was an absurd hack, but it worked really well and it amused me to write it. edit: and is a testament to how idiotic the CMD settings scheme is.
The fact that you have to go into the settings to resize it IS the problem that people make a big fuss out of. You didn't offer a solution, you described the problem.
If you want Unix on Windows install cygwin, msys, or even a virtual machine with Ubuntu, etc. It's a bit silly to expect Microsoft to provide a full Unix environment for developing Windows software.
Microsoft is running a very confusing strategy here. Google understood that with Motorola and it's why they sold it off. Microsoft hopes to keep its monopoly in the PC space with its multi-OEM operating system, yet still try to get every PC consumer to buy its own devices. Something's got to give.
I expect Microsoft's partners will increasingly continue to push other operating systems into the market on their devices, even if initially it's not exactly what the market wants. But they will do it anyway, because they will increasingly hate Microsoft.
And it will work, because the PC ecosystem is much bigger than Microsoft, and Microsoft won't succeed fighting against it. They will lose more money from lost licenses than they will be making (in profit, since so far Surfaces have continued to lose them money) than they will be making from these devices.
There could be a multi-part strategy. Both Google & Microsoft probably covet the revenue and margins Apple received from selling their own devices. Those margins, in terms of phones and tablets are probably un-repeatable. Some next iteration of device however could contain offer big margins. That is something that could double Google's market capitalization. At the least Microsoft and Google understand that they need something to give them hardware experience.
Second, it allows Google & Microsoft to lead in hardware. Even if the Surface 3 flops, the OEMs have a guide pointing what is possible and which direction to go (or not to.) I imagined this was part of the reason why Google has had different manufacturers built their Nexus products.
The Surface buys Microsoft some time. The number of people who need Office and legacy systems is going to continue to shrink as special use case stuff is built -- whether from the analytical side like Tableau to something like FarmLogs. The operating system itself may very vanish in to the background, leaving us with some unix-based combination of Android and Chrome OS.
I think there's something of a double-standard here.
I use a virtual machine running Windows to take care of software my Mac won't run natively. I could just as easily run Linux or BSD in a virtual machine on a Windows box. Or even OS X, if I were in a EULA-violating mood.
I've had to run a Windows VM on a Mac because I needed to run SSMS, but if I were doing .NET development in Visual Studio and heavily using PowerShell on the command-line, I'd probably prefer to just have a Windows computer rather than having so much of my workflow inside a VM.
Because I currently work mostly on the command-line, having a rich command-line environment with access to a powerful shell and great tools is really important to me, and I wouldn't want that to be restricted to a VM.
I always thought I'd feel similarly, but I've been doing a bunch of .NET/Mono stuff in Windows 8 (instead of using Xamarin Studio), as a virtual machine in my Mac. Works pretty great, as long as I correctly train my fingers to hit the right shortcuts when in and out of the VM.
The only downside I've experienced is really one that I'll lay solely at the feet of Windows 8: If I go a long time without checking in on the Windows 8 VM, it will sometimes auto-install updates and then force a restart. This has rather horrifying results if I had also neglected to save a file I was working on.
Moving back and forth between working on the same codebase on both the Mac and Windows sides is also a little irritating; I find the best way to do this is pumping the data back and forth between them using Git. But that would be what I have to do if they were separate physical machines, too, so I'm not terribly prepared to whine about it.
Mac OS X being UNIX compatible only matters for command line and daemons stuff, everything else is Cocoa.
In terms of architecture, Windows is a VMS descendent and although there have been multiple UNIX compatibility layers, both from Microsoft and third parties, very few people really cared about it. As of Windows 8, Microsoft killed their own implementation and is pointing people to Cygwin.
> Mac OS X being UNIX compatible only matters for command line and daemons stuff
Not really. It's much easier to port Unix-native applications to a Mac than it is to port them to Windows. Most of the time, everything just seamlessly compiles on OSX (even if they may need X to run). Also, being "closer" to the environment the app will actually run is a great feature.
To me that WAS true. Nowadays i don't pollute my local environment with services and servers and run all of it in project specific linux VMs (through vagrant mostly). OSX more or less only runs my editor, terminal and browser, something which Windows could also do pretty easily.
> It would be very interesting if Microsoft made Windows a Unix.
Microsoft's strategy has always been to make it easy to port other apps to Windows (offering POSIX services since ever) but to make it as difficult as possible to port away Windows apps. Offering a full-featured Unix environment would go against that.
Id honestly love a dock-able iPad with a sandboxed OSX app. <-- this is my prediction as to where Apple is going. They won't merge the two OSes. One would assume that they already have an arm version of OS X running, emulation probably isn't strong enough yet.
Microsoft, like Apple, wants you to only be able to use their products, so there's a very low probability of them releasing a Unix version. Both Apple and MS would actively stop people from installing Linux on their hardware if they could get away with it.
That's not the case. Microsoft make their money selling software, Apple, hardware. Once Apple have got your money for the device they don't care what you run on it. See Bootcamp.
Today many people run their development environments in VMs with something like vagrant. That, plus the fact that *nix utilities are available through cygwin, make the choice of OS to run your editor in pretty unimportant and more a matter of personal preference.
I still use a Mac but i don't use any OSX specific software apart from some small tools which i could easily replace on other OSes.
OS X is different from other Unix in many important ways that will affect you from day to day, so I wouldn't be too quick to congratulate Apple on making a Unix environment. If you want Unix, use Unix.
Hyper V has no USB support (I've often needed to pass-thru USB for a VM) and unfortunately when I first tried it with Windows 8, Debian had a bug where loading the Hyper V client drivers would crash the installer.
Just a note, if you have VirtualBox or VMWare installed and you go to enable HyperV (on Win8), you may get a BSoD.
I'm sure most of would like for Windows to integrate a Bash shell, but the moment that happens, a ton of Windows sysadmins instantly wouldn't be able to do their jobs. I bet dollars to doughnuts most current Windows sysadmins (even the Powershell people) aren't proficient with Bash. God help the GUI sysadmins if this were to ever happen.
OSX is less unix than it can get. No X. Crazy apple-only-standards... Heck you can't even use vim!
i will eat my hat if you open vim in OSX and be able to copy/paste. The + register just goes to nowhere. OS X is broken unix.
windows sucks in many regards, but it always had million more devs than OSX... i know implementing fixes on top of windows goes against the free software philosophy, but there are already too many. I can run remote X apps from another box easier on windows than OS X.
The only leverage apple ever had was IOS. you are forbidden by law to emulate IOS or OSX on any non-apple hardware. so people started to be forced to use macs. it wasn't natural adoption. And IOS is only relevant while we have dumbed down smart phones. Now that this became a standard tabled (a full computer, that you can run windows or even install linux) IOS will lose appeal, and apple will be sidelined to the history of computer history as it always manages to get it self into.
downvote with all the hate you want. you know it to be true :)
Wow. I think you mean broken X, which makes sense because it isn't based on X and X isn't included by default. The command line vim uses the X clipboard.
UNIX is a separate standard from X. IMO part of really appreciating UNIX is appreciating what is part of UNIX and what sits on top of it. I think that most server-side UNIX installs have a "broken" clipboard in vim too.
The standard distribution of vim includes integration with X11 and Windows, and that's where console vim on linux gets its clipboard from. MacVim on OS X integrates with OS X and I just fired up the console vim and saw that the "+y and "+p use the Mac clipboard.
Not sure I understand your post. I use vim everyday with copy & paste on my mac. Maybe the commands are slightly different than when ssh'ed into some box, but us vim users are capable of remembering many obscure keystrokes.
Unfortunately, I don't think Microsoft will convert many OS X devs unless they make some changes to their software. One of the advantages of OS X is that it's a Unix, and lots of Unix software runs on it. It's not hard to compile tools such as nmap, Vim, or steam locomotive.
It would be very interesting if Microsoft made Windows a Unix. They could bundle bash or zsh, add the typical BSD tools, and (most importantly) build a cc front-end for the Visual Studio compiler. They'd also have to ship a libc of their own. To save effort, they could base it on BSD's libc. It'd be like Cygwin, but installed by default and officially supported and maintained.
With such a set-up, you'd be able to run your unix tools alongside Adobe CS and Outlook. You wouldn't have to worry about driver support, since Microsoft made the hardware and the OS (just like Apple). The only thing missing would be the ability to dual-boot OS X (to test on Safari or other OS X stuff).