That's an irrelevant, flippant answer. This has *absolutely* *nothing* to do with how easy it is to install KDE.
Sorry, I don't use linked.in; feel free to mail me if you like though!
A short summary would be running a general-purpose NAS system with FreeBSD 10.1 at home with ZFS, NFS4 serving homedirs and other storage and a bunch of jails running PostgreSQL, build environments, kfreebsd, etc. And my main desktop dual boots FreeBSD 10.1 and PC-BSD, both of which work just fine. The only minor niggle is the GPU fan speed which needs tweaking due to running at full speed, but I run kde4, i3, fluxbox without any trouble.
At work, we have a FreeBSD 10.1 jenkins build node to test our code against clang++ 3.4/3.5, and I currently run a set of VirtualBox VMs for local building and testing. I may possibly switch over to it for desktop use as well if it serves work needs (currently using Ubuntu)
"Spreading conspiracy theories." Please. I may be many things, but a conspiracy nut is not one of them; there is really no need to make such silly insinuations, it's not like the prior debate was any better. The number of people who pushed for this over the last few years was very small, in comparison to the total developer base, and the GR was irrelevant to that--that was only at the end stage of the process. I'd personally long since withdrawn from the "debate" at that point, because it was so nasty and unpleasant and I had better things to do with my time than be abused by my fellow developers. A win for rude, pushy and obnoxious people who shouted loudest and longest and ignored everyone else...
While I am missing Debian as a project to participate in after spending so long working on it, I am most certainly not missing participation on the lists due to the unnecessary amount of unprofessional vitriol and bile. I'll be looking for somewhere a bit more pleasant for my next project.
After using and developing Debian for 18 years, this is the first release I have no plans to use, all thanks to the gnome and systemd idiocy. It hasn't been a nice experience, seeing a system build up with loving care by so many people over so long being willfully trashed by a small handful of people. I for one have no interest in being RedHat's bitch; if I wanted to be, I'd be a suffering Fedora or CentOS user. Debian has lost its independence and freedom.
I've been using FreeBSD for nearly 18 months now, and rarely boot up Debian on my systems or VMs. Going back 5 years, I'd never have imagined this is the way things would play out. Tragic.
3D volume rendering and large scale 2D image rendering. Modern biological and medical imaging systems can create gargantuan datasets, and visualising them is computationally expensive. The largest single images I have are ~5GiB from tiled confocal z stacks (large 3D volume e.g. 4096x4096x64 with 4x 16-bit channels is 8GiB). Current lightsheet microscopes can acquire over 1TB *per sample* in just a few minutes, with the final processed/renderable volume still being many tens of GBs. MRI scans can also be very large.
Put it this way: a 512x512x512 volume at 8 bits per pixel is 128 MiB and that's pretty pedestrian
1024x1024x1024 at 32 bits per pixel/single precision float with 4 channels is 16.4GiB
Current high-end CCDs are now 2048x2048; if I acquire with 16 bits per pixel, 128 planes and 4 channels, that's 32.8 GiB
Slide scanners can also acquire very large 2D images, well over 100000x100000 with 3 8bpp channels; that's 28.6 GiB uncompressed, and I've seen far larger.
I hope this makes the point that 12GB video memory isn't just desirable, it's still way to small for many current imaging applications without pre-processing the data to filter/downsample/reduce the sample precision. I would really appreciate a GPU with this much VRAM, and still want more.
I use a smaller ISP (aaisp.net) which provides IPv6 natively. The router they provided, which is a fairly common technicolor model, does all the firewalling and port forwarding you could desire with both v4 and v6 addresses. In the case of v6 it's more a case of unblocking than forwarding ports, since the internal address is global, but the functionality is all there and it works. If you didn't want to run servers internally, everything worked out of the box for outgoing v6--totally plug and play which is how it should be.
I set up PostgreSQL in a FreeBSD jail last week. Total setup time, just a few minutes to create the jail and pkg install the latest PostgreSQL, and set up the db cluster. Added to DNS, and it's been working ever since without a hitch, all on top of ZFS. If you're not a slave to proprietary databases, it can be very simple and straightforward to migrate to FreeBSD.
I don't have the time to point to the specific issues, but if you look over the last 18 months of the buildd-tools-devel archives you'll find them. Most of these are due the same root cause that broke tmux and screen before they were specifically patched to work around systemd.
But the specific issues are no longer worth discussing. The breakage has already happened. Debian has been broken, both in terms of the trashing of its historical reliability and robustness and in terms of the fracturing of its community. It's now past time to plan to move on to systems which aren't broken by design. If I use the new Jessie release at all, it will likely be an interim measure while it still supports sysvinit, and is just a stopgap while migrating elsewhere. While staying on Linux would be nice, it's not clear that will be viable, so pre-emptively migrating to FreeBSD will provide some medium-term security and flexibility. I started planning for the possibility of migrating away over 18 months back, and I've spent the last 12 months porting code, removing Linux/glibc-isms, adding support for BSD features and libraries, migrating systems and services, setting up BSD autobuild/CI infrastructure etc. This is now largely complete, just need to finish ZFS snapshotting for schroot.
Never forget that Linux wasn't made by big companies pushing their agendas. They largely picked up what others had created before them. Big UNIX tools and programs are as a rule crude and less featureful and polished compared with their free software counterparts. Linux was made by the thousands of people who created and polished the free tools and programs to make them the most featureful, portable, useful and usable of their class. As a group, we've been collectively given the finger, and so many of us will take the message and move on. We'll see how well the latter day Big Linux companies do without us in the long term. They may well have killed the goose that laid the golden eggs.
What stopped me? Many things. Here's a few.
The systemd debate reduced the Debian lists to an endless flamewar over three years long. debian-devel is just toxic; it's not useful for any constructive development discussion. I unsubscribed from almost all the lists a year back. I can't describe how wearing and demotivating this is. Reading the archives since then, it hasn't improved.
Most of the software I write for Debian is core systems programming stuff. Straight out of APUE (Stevens). Over the last year, I've had a stream of bug reports about things not working correctly under systemd. Some fairly fundamental POSIX syscalls and tools no longer have the same behaviour when running under systemd. By "design". That's a fairly huge compatibility break with every other UNIX-like system out there, and one which hasn't seen much attention. But I'm somehow expected to rework my code to work around the breakage systemd brought with it. Breakage which has nothing to do with me. Code which isn't even remotely anything to do with an init system and which is portable code running on many other systems. That's crossed a line. systemd can't and won't be supported.
I can work on sysvinit, openrc to a lesser extent. For several years it's been all take and no give with the systemd people. We can't do work on integrating openrc since this would require support for runscripts in systemd. What's the chance of that? Zero. Any changes, even minor ones, require superhuman effort to achieve. Essentially, it's an uphill battle to do anything and Debian is no longer a pleasant or productive environment to work in, primarily thanks to the horrible "our way or the highway" attitude of the systemd people. Since when was free software about dictating how everyone must do things? Silly me, I used to think it was about having the personal freedom to tinker with things as I liked to meet my needs. I'm a volunteer, and I give up vast amounts of my life to contribute to free software and Debian. This was previously a fun, collaborative, productive endevour for which my efforts benefitted many people. It's now deeply unpleasant and I don't like being abused, ridiculed and trodden on by the systemd people and their enablers. I'll move on to new and better things. I spent the last decade as the primary maintainer of the core Debian build tools, and later of sysvinit. I've been invested in and contributed heavily to Debian for the last 15 years. Not something easily let go.
We'll see how Devuan pans out. Until it does, I'll be carrying on the migration to FreeBSD.
Altruism only goes so far.
This isn't strictly correct. They have been talking about their own equivalent of launchd.
Why is the distinction important? Unlike systemd it has a clearly-defined and limited scope. If systemd had stuck to doing this, it wouldn't have become the creeping mess it is today. So long as the FreeBSD implementation is limited and sane, I see no reason why it won't be a general improvement. And given the clean and generally machine-editable nature of rc.conf and the BSD init system, it will likely not be too challenging to make it backward-compatible, which is another area systemd failed in by not being fully LSB compatible.
Really? I can.
I'm a Debian developer who has been moving slowly to using FreeBSD on more and more systems over the last year, displacing Debian use and development on those systems. I've started contributing in minor ways on the lists and the odd patch for the ports tree. I'll likely start packaging my stuff in ports and becoming increasingly more involved over time.
I contribute to things I'm actively using. For the past 15 years, that was Debian. Unfortunately due to the best efforts of the systemd people, it looks like that's unlikely to continue, though I very much wish this was not the case. But reality can't be avoided, and this is where things are today.
MacOS X and Windows are both second-class citizens. They work poorly and inconsistently, and are not well-maintained ports. You can't build a Windows or MacOS X version of a GTK+ application and expect it to work properly. With Qt, you can. Nowadays with GTK 3.x, even non-Linux and non-GNOME are no longer catered for properly. This isn't new. Windows support was mediocre back in 2004 and it's still mediocre today. MacOS X is arguably worse. Case in point: copy-paste was broken in Inkscape the last few times I've tried it on MacOS X, making it unusable. This is simply due to the primary upstream developers, those that are left at least, not caring at all about these platforms--they never have cared. Working "quite well" is a low bar; stuff needs to work all the time. It's true that it works for simple stuff--a few buttons and text entries. But at soon as you get to a more complex application that starts to use more functionality, you're in a world of frustration as you discover the extent of all the brokenness.
A decade back, GTK+ used to be my toolkit of choice, and I was using it for my day job for a while for use in actual products, writing tutorials and articles on it in professional publications etc. In retrospect, it wasn't that amazing then, the systemic issues it has were there since it began, but it's not even on the radar today for most developers. I'm now a Qt developer, like many others who had to get stuff done and found GTK+ sorely lacking. Building cross-platform OpenGL rendering stuff, it works on every platform without trouble and looks and behaves completely natively, and is a pleasure to work with rather than an exercise in masochism. In 2004 I was regularly filing bugs with patches against GTK+. A few months back, I saw some get closed/wontfix--10 years of tested, unreviewed patches fixing serious problems being ignored and abandoned. What a waste. If it was actually maintained properly, I might possibly still be using it. But if bugs which block your work don't get fixed, even if you put in the effort to fix, test and submit the patches yourself, you end up having to move to something which is actually maintained properly, such as Qt.
I'd argue that the issues are still with Microsoft. They could (and previously did, up to OpenGL 1.4) support OpenGL natively as they do with DirectX today. The hardware vendor shouldn't have to implement and provide a complete GL implementation, but they do have to, and this is one reason why GL implementation quality varies so widely. It could have been a very different story if they weren't a bunch of manipulative control freaks.
If Microsoft provided a fully-featured GL implementation and let vendors provide a much lower-level driver to do hardware abstraction only, the experience would be much better. This would be akin to Mesa, where the hardware drivers target Gallium and not the high-level GL/state machine side of things. A single GL implementation with multiple backend drivers (OK, I know it's not that simple in Mesa-land, but I hope it makes the point).
I used to be a "C" zealot who considered it unmanly to use other languages. I've got past that with age. C is simple, but it comes at the cost of having to do every last thing by hand. Even when it's unnecessary and the chance of making mistakes is high. After spending years on the nitty-gritty details, there comes a time when you have to ask: do I really need to implement the needed bits of a vector/list/set/map/hash or do I just use one that I know will work without any trouble. Chances are it's optimised better than my hand-rolled one would be. And it takes a few seconds to use, since I don't have to write all that wheel-reinventing code myself. I can focus on the problem I was trying to solve, rather than unnecessary groundwork.
Stuff like std::vector is often criticised by those who don't appreciate what it does. After optimisation, element access is as efficient as a C array, and the automatic memory management is no worse than what you'd need to do in C anyway. And it's type-safe and exception-safe. Same with std::string. This is also often more efficient than using the C string functions (though obviously can be less so if used badly). But it's safe and easy to use, which is the big win. How often have you screwed up C string manipulation. That's right, we all have, and even when it appears safe and working, it's often a disaster waiting to happen.
I'm replying to this because as I was reading through I was working on some code for work. We were using std::vector in a set of nested objects to keep track of their children using std::shared_ptr, and to allow cross-references with std::weak_ptr. Works just fine. But profiling showed that our usage patterns were suboptimal. We needed to keep track of objects by their insertion order (linear) but also needed to do fast lookups (set/rbtree). I could have hand-rolled a custom implementation, or made a custom container with embedded vector and set objects and logic to keep them synchronised. However, a little research and this was the solution:
template<typename T, template <typename ElementType> class Ptr>
boost::multi_index::ordered_unique<boost::multi_index::identity<Ptr<T> >, std::owner_less<Ptr<T> > >
Total time from finding the problem to researching and creating this working solution (including converting the existing code to use it): 2 hours.
So now I can do indexed_container<foo, std::shared_ptr>::type c and get a custom container containing std::shared_ptr<foo> indexed by both insertion order and by pointer value. With C++11 I could use a templated typedef and also avoid the struct wrapper. And multi_index_container template is usable for all sorts of esoteric multiple-indexing with indexing on individual/multiple fields or with custom functors or whatever you like. Why would I want to reinvent that when there's a pre-canned implementation that just works. It certainly has intellectual value, but when you just need to get something done, the above is using the available tools to best effect. Imagine how many hundreds of lines of C the above typedef would require to reimplement from scratch. And how many man hours would it take to implement? It's just not worth doing that.
This is all highly debatable!
However, if you had to choose between GObject-C and C++, the rational choice is C++. It's the better choice on all counts: safety, speed, correctness, robustness, maintainability. I had to learn this lesson the hard way by spending years banging my head against the wall using GObject when I could have just used C++.