If someone is coming from a Microsoft experience, with their separate Windows desktop and server releases, it might make sense for Linux to follow the same paradigm, except that Windows desktop is the same as Windows server, just with certain server features crippled. In that respect, Linux never deliberately cripples itself.

However, if Linux is to follow the Microsoft paradigm, then keep systemd on the desktop version, so desktop users can enjoy a buggy/crashy experience, and keep systemd off the server version, so it runs smoothly.

Joking aside, the article doesn't make much sense. There are a million distros out there, and if you want to customize one with specific packages for specific work loads, just start with a minimalist system like Gentoo, Arch, or swtich to one of the BSD's.

Bill Gates: http://www.globalnerdy.com/wor...

Both achowe and 3vi1 have very good points. To expand on one of 3vi1's points (with which I agree completely), volunteer, open-source development counts as a hobby. Good devs don't work for free.

Sure, everyone makes mistakes, but if customer A wants this feature and customer B wants that feature, the design can change and bugs will result. The analogy here would be if a bricklayer lays some bricks and the architect says, "I changed my mind, let's use marble instead," the bricklayer is paid to replace the brick with marble.

Programming and construction are different beasts entirely. While some analogies work comparing the tech field to other fields, many analogies fail. Your bosses analogy just doesn't fit the tech field.

The link didn't load for me, but in general, "because people use it incorrectly" isn't a good reason to stop using something that is useful when used correctly.

If you can tell me more specifically what you want to accomplish, or the format of the data you are trying to manipulate, I can (hopefully!) point you towards more specific tools—there are just too many command line tools for data/text manipulation in linux, though most are available through cygwin (still a bit of a hack solution, but if Windows works best for you as an OS, then we'll find a solution for you in Windows).

Also, OpenOffice (or Libreoffice) is just another office suite, like MS Office, so it's still pretty bloated.

"Less useful but still useful are command shells." A command shell is only as useful as the CLI support. If you're using Windows, whose programs tend to have weak CLI support, then a command shell will be less useful.

"What else is out there?"

I recommend searching for the "tacobell programming" article. I use linux/bsd systems and almost all programs support CLI's. By using pipes, you can string several commands together, using one program's output as the next program's input, all on the command line. It's very, very powerful. There are so many programs I just take for granted, that when I use a Windows machine, I feel neutered without programs like grep, vi, dd, ctags, cat, head, tail, netstat, nmap, locate, less, sed... the list goes on and on (note, there are Windows versions of some of these programs, and they are available with cygwin for Windows, which provides a sort of decent unix-like interface for the Windows OS).

I think this is a great idea. It would be especially ironic since Apple banned the drone strike tracking app from their app store.

People aren't necessarily people with morals either.

I'm twenty-seven years old.

From my limited experiences, "current" has nothing to do with it, nor does age. C has been around since there early '70's; in terms of systems-level programming, there is a huge benefit to being older. The older folk have seen tons of OS's born, raised, reach adolescence, get their first DUI, etc. They know what's it's like to play in a kernel that only has 256 KB of RAM, so they know how to optimize. Lots of youths these days are given higher and higher level languages as intro programming classes. My alma mater, to my dismay, replaced Java with Python for the intro class. I wish I had that insight. We younger generations are missing out on a lot of experience, and as more and more development moves to the web, lots of us are missing out on what really goes on under the hood.

Now, to address some of your statements:

"I work with a developer who is 10 years my senior, but still doesn't understand how to write concurrent code" This is a symptom of poor programmer quality, and has nothing to do with age. You can be 5, or you can be 65, but if you don't know what a spinlock is, then you don't know what a spinlock is. Multi-threading/multi-programming has been around for a long time.

"and cannot be trusted to use a revision control system without causing a mess that somebody else will have to clean up." I still have no idea how to use a revision control system. However, it's good practice, at least for me, to befriend someone who does understand them, so he can help you the hard times.

File-level caching also has a lot of disadvantages. First and foremost, as you mentioned, it has to be tailored to specific file systems, like NTFS. For Linux and Unix OSs, there are so many file systems that porting file-level caching software to every one of them would be a nightmare. Linux/Unix has a generic block layer, so block-level caching software written for Linux/Unix is file system independent.

Second, the list of heuristics can easily spiral out of control. You might not want to cache a video file of a movie you're watching, but you probably would want to cache a video file of a movie you are editing. You have to know where the file came from, where it's going, how fast you want it to get there (i.e., priority), what programs are using it, etc. There's just too much contextual metadata that needs to be tracked; the more complicated the contextual metadata is, the more complicated the heuristics need to be. Also, statically defined heuristics may be inappropriate for dynamic environments.

Third, why cache an entire file if you're only working on a very small percentage of it? I have to admit, some file-level caches will only cache the "popular" portions of files, but in that case, why not just use a block-level cache and enjoy its better performance?

Also, I'm confused about "there are a lot fewer blocks than files," did you mean that the other way around? If you have a single 100 MB file, and the system's block size is 4K, you have a lot more blocks than files. There may be a smaller memory overhead with a file-level cache, but there's a greater CPU overhead due to all the contextual metadata and heuristic processing.

The features have been in Ubuntu forever, true. I was referring specifically to Unity. Ubuntu 10.04 with Gnome2 was my distro for the longest time before Unity convinced me to go distro hopping. I still think 10.04 was their best so far.

Painstation has been around since 2001, and features heat impulses, shocking to the palm of the hand, and whipping to the back of the hand.

Why should Twitter waste effort sending any private data to the government when the government can just easily hack Twitter accounts?

So far, the only review I've read about Ubuntu 13.04 said that promised features such as more customizable privacy settings and Smart Scopes didn't make it into the release because they were too buggy. It's just too amusing to have read that review the day after I read an article about how Ubuntu is ditching the rolling release model. Guess Ubuntu users will have to wait until October.

Other amusing features in 13.04: a button that shows the desktop, and a workspace switcher (disabled by default) that lets you know which workspace you're currently using. Wow, Ubuntu. Unity is on pace to have all the desktop features that Gnome 2 and Xfce have had for years by 2016.

The client wants you to use Muse. The client wants more control of the site. So, the client should pay for Muse. Making you pay for Muse would be like making you pay for the web hosting and domain name too.