As for me? I switched to the Mac. No more grep, no more piping, no more SED scripts. Just a simple, elegant life: “Your application has unexpectedly quit due to error number –1. OK?”
The great thing about a Mac is that I get to have my user level UNIX without having to know anything about the system level UNIX. I don't need to be a sysadmin to run the thing. I get grep and pipes without having to know all the crazy commands to tweak networks settings and display timings and boot scripts. When OSX came out, that was the state of Linux, you couldn't be just a user of it, you had to know way too much to get it running.
The team behind WSL is also very responsive to issues reported at github.
Luckily, that is basically true for modern Linux as well.
I ask as I type from my Dell XPS 13" DE (aka Sputnik).
> http://www.cnx-software.com/2016/10/14/ubuntu-16-10-images-r...
Seemingly confirmed here:
> http://linuxiumcomau.blogspot.com/2016/10/running-ubuntu-on-...
Where this guy updated to say that current ISOs of 16.10 should work...
> Whilst two ISO sets of various Ubuntu flavours for both 16.04.1 and 16.10 releases are provided, I recommend first trying one of the 16.10 ISOs as these are the most recent and incorporate the latest kernel, patch sets and fixes based on previous releases and feedback. In particular, the Yakkety 16.10 ISO kernels support micro SD cards (although with some limitations), includes a patch for I2C bus, has improved RTL8723BS wifi and bluetooth support and most recently I've included support for full disk encryption on Lubuntu and fixed the home directory encryption for all flavours.
OpenSource tends to have a lag time to hardware by nature...but I do believe there was some exaggeration here.
All the time the argument is given that OS X has much better hardware support than Linux, which is just not true. It might be true for OS X on a Mac compared to Linux on unspecified hardware. However, if you constrain the hardware choices even half as much as you do for OS X, that's not the case anymore.
Mac resurgence is more of a perception than reality. In 2016, Apple sold ~18.5M Macs, down from the previous two years [1] and off more than 10% from last year.
Granted that the Mac numbers are falling at a slower pace than the PC market as a whole, but resurgence is probably an over-characterization.
[1] http://finance.yahoo.com/news/state-apples-device-sales-1940...
Given that Mac has gone from well under half a percent market share to over 7% today, I'd say "resurgence" is an under-characterization, relative to what I was talking about. ;) OS9 never had the market share that OSX has, so it's less coming back, and more dominating like it never did before.
Fedora/Gnome here. I never use this sort of stuff, and modern power users really don't have to. That's why I categorically state that practically no-one in the real world "uses Unix", even though most OS-es incl mainstream mobile ones derive directly or indirectly from it, save for Windows and esoteric ones.
Do I enjoy modern Linux? Heck yeah. Do I want to use Unix? Piping and grepping and cat'ing and touch'ing and so forth? It's not rocket science but it's also a doggerel not smooth UX for me, and "not smooth" means not productive.
If I need to compose functionality for "shell"-based task automation, I whip up a small Go program. Portable across OSes should I ever move, bin dir is in PATH, compiles fast enough to not need script interpreter for iterating the "script" (tool) at hand, and the syntax and semantics are saner to me than sh scripts, aka no impedance mismatch vs other coding tasks.
(Sure enough though, for one-offs "search these for that" while already in the bash/etc, the built-in old-school tools still come in handy occasionally)
OTOH working on some non-trivial code bases, maybe including system level code, typically requires grepping and piping, for at least some developers of the team, to be productive.
I too don't gratuitously use cat and touch and grep when I don't need to. I even less often use cmd stuff under Windows (using one of the dozen of bash that exists there is better for interactive command line use, when needed, on computers where I can have those), but if I need to I can do it.
Do I use Unix or not when I'm not typing into a traditional command line shell, but still using a Unix-based system as my direct terminal (or a light terminal connected to it)? "Interesting" question. Do I use an internal combustion engine when I'm driving a car? Do I use electricity when I switch on the light? I don't think we can answer any of those questions in a truly absolute way. But most of the time I would probably say yes.
I bought a macbook thinking I'd learn how to use it... but after 3 years, all I can do on a Mac is open a web browser and terminal.
Using Finder, XCode, Objective-C and Swift frameworks,...
Objective-C looks like a clusterfuck and I never want to touch it. Swift seems like a quite good solution to that and I hope it eventually becomes the full replacement - but now more non-Apple laptops have high DPI screens, so I don't think I'll be around to see it happen.
The nice thing is that it is configurable.
This is pretty much moot now, the Apple world is abandoning Obj-C, but AFAIK it's just old, not bad. Like, came out at the same time as C++ old, and has seen fewer changes to the language than C++ has. It's a compiled, C-like language, so yeah, hard to use and very easy to crash, just like C & C++.
Interested to hear your point of view on what makes it seem like a cluster, if you want to share. (And I'm only interested in hearing and understanding your opinion, not on debating or contradicting your experience.)
Obj-C had a pretty cool calling mechanism underneath, known as "message passing" -- more or less the analogy to C++'s virtual member functions. But it is the only compiled language I know where you can actually call functions by name, like construct a string dynamically and call, and you get those dynamic calls at the same speed as compiled code (minus a fast function lookup you can usually do once).
I used that mechanism in some games to build a nice state machine class for actor behavior. I did the same in C++, and the Objective-C code was way nicer & easier to use.
You can do this as a hack in most compiled languages by exporting symbols from a shared library and just using the OS specific dynamic linker but this is ugly, slow, and pointless in a static language.
It's called by various names - not sure if there is an official one - such as dispatch tables, jump tables, dynamic dispatch, etc. It's a pretty old technique, I would say it probably dates from the time of early high-level languages, and I seem to remember that it was used in assembly languages too (so probably even earlier), by using various addressing modes (indexed, indirect indexed, etc. (those terms are from long-forgotten 6502 instruction set BTW), storing the address of a function at a location and then jumping to that address (where the address is dynamically set at run time by some other bit of code based on some condition), etc.
Here is a simple example in Python:
Simulating the C switch statement in Python:
https://jugad2.blogspot.in/2016/12/simulating-c-switch-state...
Edit: Googled and got a couple of relevant links:
Know what drives me the most nuts? That there's a single default key (Enter) to rename a folder, while you have to use a key chord (Command-O) to enter a folder. It's so backwards, renaming is not something I spend even remotely as much time doing as moving around. That's not to mention the so completely obvious missed opportunity to let the Enter key do what it says and Enter the folder.
I use Command+Down, which opens Finder shell-objects generally. It's the "descend" to Command+Up's "ascend."
Still, all navigating should be single-key-able, right? I guess it is technically, with left & right arrow keys in the List & Columns views, but I don't use those or like those as much, for whatever reason.
>I don't know why people seem to think Apple is some sort of UI god when they can't even make a usable file manager.
I know! I ask myself how this is possible every time.
The irony is now I run Linux in a VM because the toolchains for the embedded work I do all run there. In principle I can make it all work in MacOS, but it already works in Linux.