Back in 1998 I was at a Perl conference in San Jose, California. The SUSE folks were there and handed me a copy of OpenSUSE. I installed it, loved it, and have used it ever since -- until now. Over the past couple of years, I've kept my eye on Linux Mint. I liked what I saw. Recently I was in the mood to upgrade my trusty Linux VM running in Oracle VirtualBox. I finally settled on Linux Mint and had everything up and running fairly quickly: CrashPlan, MySQL, Ruby on Rails, Guake Terminal.
I ran this for a couple of weeks and decided to give the latest OpenSUSE a try: Leap 42.1. Well, as usual, it was much more laborious. For instance, I had to refresh my memory on how to get CrashPlan to start automatically. I worked long and hard to get all the various Ruby on Rails libraries compiled. And MySQL? Well, MariaDB is pretty good, but MySQL Workbench, while it works, just doesn't work as well and constantly nags about certain features not being available.
But, after working all day, I had most everything I needed. Except one thing: Linux Mint just looked better. The fonts were more appealing, and in general, everything was crisper and better looking. So, I thought: must be the Cinnamon desktop. I did really like it. So, I installed Cinnamon in OpenSUSE and gave it a try instead of KDE Plasma. Nope. Still did not look as nice.
So, I went back to my Linux Mint instance, despite it still complaining about running in "rendering mode" (OpenSUSE when running in Cinnamon has the same issue on my laptop under VirtualBox). Guess I'm here to stay for a while. Nice distro. Still favor OpenSUSE in some ways. It's a bit more industrial quality, but Linux Mint is far more appealing -- and it was far easier and faster to get all my favorite stuff up and running.
From that point on you can use a two-way sync if you like
My transition to the iPhone was made easy by several years of using an iPad. Android is getting so very good, that it's a toss up which OS you prefer. The key with Android is to get a phone you're happy with.
For me the iPhone is the Cadillac of phones. Android is the Chevrolet. Both are nice, iPhone is a bit more luxurious -- and most of the time that's good, sometimes not so.
"I'm not inclined to make grand pronouncements about the future of software, but if anything kills off commercial software, let me tell you, it won't be open source software. They needn't bother. Commercial software will gleefully strangle itself to death on its own licensing terms." Jeff Atwood http://blog.codinghorror.com/why-ruby/
Recently we went through an exercise at work in which we tracked down every use of the Oracle database for licensing audit purposes. In particular when I found out that a web app must now be tied directly to an end user I was incredulous. Why? On the back end we had a licensed "service account" accessing Oracle. We were in a sense simply providing a report view to whomever came along to use the application. Seemed reasonable to me, but I was very naive.
So I second guessed IT management as I so very often do and looked into the issue myself. Unfortunately I found out that management has a right to be concerned. Even our company with its in-house lawyers was right to bring in high paid consultants to navigate Oracle's licensing. Suddenly all the Microsoft SQL Server fans were gloating. Gloating that is until they found out that Microsoft was moving in the same direction as Oracle and our existing licensing would expire at the end of the year.
So, I agree with Mr. Atwood: licensing could kill commercial software. It made me glad that my prejudice for personal projects has always been in the direction of free and open software development tools.
When I got my iPad4 a few years ago I was amazed at the battery life and rapid boot -- though most of the time it was just waking up from sleep. I hardly ever shut it off.
These days I've seen what an Ultrabook with lots of RAM, a decent CPU, and a solid state drive can do running Windows 7. Now I understand my iPad better. It's always had a solid state drive and a reasonable about of RAM.
For too many years I compared Apples and Oranges. Now that Ultrabooks have similar hardware to iPads in the form of solid state drives they are very comparable, much more useful, and if you put them to sleep as frequently as my iPad sleeps, their battery life is just as amazing as that of the iPad's.
Lately I've been doing a lot of Visual Studio development at work and at home. I don't like rewriting or copying common code from project to project. I strongly believe in the "DRY" principle of programming: "Don't repeat yourself." On the other hand, package management can be a pain.
Installing third party software using NuGet is now so very easy. But I was not the only developer that thought it would be complicated to create and manage our own Nuget packages. How wrong I was!
Creating and managing NuGet packages could not be easier, and NuGet takes so much of the pain out of managing shared code. It comes installed by default in the latest versions of Visual Studio, and if you don't have it, you can install it as an ad-on.
Here are the simple steps to creating a NuGet package and making it available to your Visual Studio projects (or other software that accesses NuGet like MonoDevelop). These steps assume a C# project only because that's what I've been working with.
Create, write, and build a library project (this is where you compile to a ".dll" file). Your shared code will be in the .dll
From an MS command shell, CD down into your project directory (typically one level lower than your solution). This is the directory where your ".csproj" file exists. (Assuming your doing C# development.)
Edit your project assembly information (either through project properties or by editing AssemblyInfo.cs directly to fill in program description, company name, etc.
Run "nuget spec" to create a new ".nuspec" file.
Edit the nuspec file as you desire. Once you run the next step, you'll know better how you want to edit it based on the warnings you get form NuGet.
Run "nuget pack" to generate the ".nupkg" file, like: "CommonCode.184.108.40.206.nupkg"
Copy this and all other such package files to a directory of your choice. If you're sharing this with others, make sure they can access that directory. (This is the easiest way to create a NuGet repository, and the focus of this example.)
One time only: go into Visual Studio Tools->NuGet package manager->Package Manager Settings and under "NuGet Package Manager->Package Sources" add your package directory as a package source, naming your new "repository." Be descriptive and concise.
Now when you have a solution open in Visual Studio, go to Tools->NuGet package manager->Manage NuGet Packages for Solution, look under "Online" and you will see the repository you added and whatever packages happen to be there.
I love CrashPlan (http://www.code42.com/crashplan/), but: by default it backs up EVERYTHING in a user's home directory. This creates real performance issues on Windows even if CrashPlan attempts to go easy on you while you're working. Even in Linux it can be a problem as applications like Firefox and Netbeans create so many hidden directories and files under your home directory. And then there's DropBox that never really deletes your files unless you work very hard to make sure they are gone.
So, I have found the best strategy is to go in and completely de-select my home directory when configuring my CrashPlan backups, and then add ONLY the few things I really care to back up.
BIG GOTCHA IS THIS: be sure to check the box that says "Show Hidden Files" or you will still get too much activity as Windows creates all sorts of junk files in your home directory.
Ah, at last, I can get some work done without putting CrashPlan to sleep.