Windows 8 Is Coming and I Don’t Care

Well, that’s weird, I would never expect Windows rant for you. Let me explain and clear up some of your statements according to how Windows 8 works now (after about 2 months of using RTM version plus using previews since day one).

First, Windows is more close to OS platform than ecosystem. That is, Windows is more like Linux kernel + Xorg than like Linux distribution/OS X. Until Windows 8 they didn’t even try to have some ecosystem, adding Marketplace, Modern UI and WinRT is just adding ecosystem to existing (updated) platform – with heavy integration, but still, as part separate to platform.

Second, a lot of settings are application-specific. This is done to allow application developers and administrators have control about how various instances for single user share data. Microsoft-created apps (Windows itself, People+Calendar+Mail Modern app, Office 2013) use Live account and SkyDrive to synchronize their settings. For paid applications often have (paid – usually) server options for synchronizing/migrating data and settings (a lot of them is made to be easily integrated with Active Directory and corporate accounts), each one independent from system-wide settings and account connections. It is now possible to have personal settings (contacts, wallpaper, OneNote) synchronized with personal account while still having Outlook/accounting program configured by Active Directory. Microsoft still considers corporate environments as key target, so they can’t just drop support for all of it.

Still, some settings for applications are easily transfered between system installations. Those are contained in %APPDATA%/Roaming directory – by design all (and only) settings that can be safely moved to another computer should be placed here. %APPDATA%/Local is by design local only and not to be moved, settings here may be even installation-specific, similar differences are with registry. So, unlike Unix, Windows takes note that some settings/data should not be moved between computers.

BTW if you want to test full potential of Active Directory on Windows, try some VPS with Windows Server and configure AD for your Windows devices. Also, there are no tablets with AD support, so having Windows AD-compatible tablet will be green light for some corporations with strict security rules (also, configuring AD is far cheaper than buying similar solution for Android).

According to DLL Hell, main and only reason is to preserve as much backward compatibility as it’s possible. Each application contains its own DLLs, because they’re distributed as self-sufficient. It means, that installing any app should not break or do any harm to each and every installed previously or after it, including older versions. For big applications (accounting, architecture, even for MS Office or Adobe Creative Suite) updates can be quite expensive, so it’s plus for people to have possibility to stay with one application version on two or three Windows releases (I know people using still Adobe CS2 since Windows XP).

Lack of binary compatibility and self-sufficient package is very painful on Linux, where updating system packages can break existing apps (if they’re from outside package manager). I spent several hours today looking for distutils working with compiled libc 2.3.14 (it’s version from 2007) to fix broken CentOS installation – there was no way to build new libc/distutils without breaking entire system. In cases like that having self-sufficient app (only package that must be installed on Windows is msvcrt, everything else is usually provided by installer) or incompatible versions, DLL Hell becomes DLL bless.

When talking about shell and command line – painful and true. Powershell is far from bash capabilities, even scripting with .NET can’t help much.

You can wake up when Windows RT tablets hit the marker. Platform layer will be cut off, leaving only ecosystem layer (Modern UI and Marketplace), so giving you something similar to what you want from desktop OS. For me as user it is important I can run my old applications on newest Windows, also as application developer I can be sure no twisted installation options (except heavy OS hacking, then it’s users fault) will render my application broken.

Aren’t OSX applications usually self-contained? Aren’t Android and iOS apps self-contained by convention? Self-contained has been the way to go for years now.

Size isn’t normally a problem and people don’t really dig dependency hell.

@Asmodeusz:

First, Windows is more close to OS platform than ecosystem. That is, Windows is more like Linux kernel + Xorg than like Linux distribution/OS X.

That really sounds like evasive action. For one, I doubt you’d find many users – even tech savvy ones – that can easily tell the difference between one and the other. As far as they are concerned, Windows is thing that makes their apps running. That it doesn’t pretend to be an ecosystem is unfortunate, because one has just naturally evolved over the years of its market dominance.

Microsoft still considers corporate environments as key target, so they can’t just drop support for all of it.

That’s great if you’re company buying into Microsoft solutions. From the PoV of home user, something like iCloud works much better, though. I see that SkyDrive is a kind of response to that so there’s probably some hope yet ;)

Still, some settings for applications are easily transfered between system installations. (…)

These (i.e. Roaming vs Local) are actually pretty great conventions. I wonder, though, (1) how many apps follow them correctly, and (2) how many users are aware of them and can leverage them to their benefit. It’s certainly a kind of knowledge you could benefit the world by spreading :)

Each application contains its own DLLs, because they’re distributed as self-sufficient.

Instead, why not have the application declare which external libraries – and in what versions (possibly as ranges, e.g. >=2.4) – are required by it? The system could maintain more than one version of any library X, of course. No breakage happens, and it’s always possible to tell which application is using what libraries so you can remove unused ones if so desired.

Of course, overlaying something like this over existing Windows infrastructure would be pretty damn hard, as it’s essentially introducing a packaging system from scratch. Benefits would be enormous, though (automatic update of all applications – not only Microsoft ones – being one of them).

Lack of binary compatibility and self-sufficient package is very painful on Linux, where updating system packages can break existing apps (if they’re from outside package manager).

Emphasis mine. There are two ways to break the bonanza of dependencies: make them public and explicit (system’s business) or make them private and implicit (app’s business). Linux uses the first way and if your rogue application doesn’t comply (e.g. by linking to .so rather than .so.specific.version), it is asking for trouble.
As for your specific problem, I have no idea how the packaging/dependency management works on CentOS so I’ll refrain from commenting on it.

When talking about shell and command line – painful and true. Powershell is far from bash capabilities, even scripting with .NET can’t help much.

Powershell is actually fine by itself, and certainly on par with bash as shell. As scripting language, it might even get a bit ahead (no weird syntax, whole .NET at your service, etc.).

The miserable state of Windows CLI boils down to two things, really. First is the terminal itself, which I touched upon in the post. The other is about the whole thing being really an afterthought compared to GUI tools. Powershell cmdlets might get you somewhere but you don’t really have the freedom to tie them with external tools due to inherent .NET->text boundary, pretty much impassable in the opposite direction.
(Concrete example: pipe the result of `netstat` into Psh and extract active connections to IPs from particular subnet. Will you convert the IPs into .NET objects and operate on them, or just use regexes? What if the subnet is not /8, /16 or /24? :))

@Kos:

Dynamic linking in OS X is very similar to that of Linux. I’d presume Mac App Store uses that to manage dependencies behind the scenes but I don’t really know much about it.

Mobile apps vary significantly when it comes to dependencies. iOS ones are indeed self-contained to the extreme, and this is one of the platform’s liabilities. Android, on the other hand, provides many avenues for interoperability and component reuse (e.g. calling activities or services). As mobile apps are typically not very complicated, there are limited uses for it beyond some data exchange, though.

Self-contained has been the way to go for years now.

Ah, those golden years where every game had its own Sound Blaster drivers! ;-)

Microsoft reminds me the famous opera La donna è mobile. Always changing, is not serious. Bloody Windows.

About declaring external dependencies by apps and automatic handling them by Windows:

You’re probably aware of that, but since Windows XP there is Side by Side technology which does exactly what you want, however not necessarily how you want. App declares SxS manifest where all required DLLs and their exact versions are specified. Windows automatically loads appropriate ones. Also it’s possible to override version requirements by specifying redirection to newer version of DLL. The biggest disadvantage is space taken by winsxs folder, which is pretty enormous since Windows Vista. Even more – once DLL is stored by SxS mechanism, it can’t be deleted at all. Folder is by default manageable only by SYSTEM user, which is very annoying when you try to remove windows.old directory or such.