Hacker News Reader

Comment by wadd1e | Hacker News Reader

I have a bit of a perfectionistic tendency to 'start over' things over and over and do them again as perfectly as possible; the Windows side of MS feels like a corporate embodiment of this habit.

They've done this sort of thing with app installers(setup.exe, click once, appv, msi, msix) and UI frameworks(win32, mfc, wpf, winui 2, winui 3). It's like the teams responsible for their respective product keep starting over with a shiny new way of doing things every couple of years to achieve the 'perfect' installer/ui framework or anything else for that matter. Infact W11 felt like a way of 'restarting' W10 without building a whole new OS.

Atleast with W11 they're actively updating old things rather than introducing new ones, I did not have a lot of hope when it first came out, but they have gotten my hopes up since the release for sure. I just hope they stick with winui 3 and see it through.

View on HN

Well, if you're UI designer and designed the UIs launched it and all works... what else you're going to do ?

Same disease that plagues GNOME, change shit for sake of changing shit, fuck users that got used to the old way, they don't matter, is new way faster ? Who knows, we don't.

It's funny how the huge silent majority get on just fine with GNOME but the vocal few act like the devs have poked them in the eye and called their mother fat.

Well, I'm used to Ubuntu updates breaking my workflow and potentially breaking some of my boot services, which is genuinely inconvenient. So I don't think those vocal few are wrong.

What does this have to do with GNOME?

Ubuntu defaults to GNOME for its desktop environment?

What does that have to do with Ubuntu updates breaking things? If a tornado hits McDonalds while you're in it are you going to say you hate McDonald's for not being tornado proof?

And they are really angry about it!

I use GNOME, it's not great, but some people really hate it, go out of their way to tell everybody how pissed they are at it and that GNOME is the worst thing to have ever happened to the Linux world. I guess complaining about GNOME has become part of their identity, a trait shared by the vocal systemd haters that just won't shut up about it.

Many Linux users haven't gone past the "it's cool to hate" teenage phase. Goes hand in hand with the obnoxious elitism and anime avatars.

Hating shows their lack of skills. They are the kind that know just enough to complain but lack any significant skills when it comes to development. They probably work in some point and click system administrator job. Eventually they either learn they can lead the change they want to see in open source and shut up because they aren't willing to do it, or they keep throwing a fit like a baby thinking that'll help them get their way.

I've despised GNOME since version 1.x. I've developed a solution to deal with all this pent up hate and rage toward GNOME.

I just don't use it.

About as desktoppy as I'll get is XFCE. I gave my girlfriend (now wife) a Kubuntu-based laptop once to hold her over until I bought her a MacBook Air.

Systemd is another matter because Lennart doesn't seem to want me to have the "I just don't use it" option without stuff breaking. But Void seems to truck along quite nicely with runit so I'm content with that.

As I recall, the UI designers didn't even ask for feedback. It was a case of "we know what you want better than you do". That design approach is basically always a mistake.

Well, yes, but if most people who is going to give feedback are tech-inclined Linux people and your aim is to build something which can be used by anyone at the end?

Your initial design might land somewhere very wrong, but starting to ask for feedback from that point on will lead you better since it's wrong for everyone, no?

The word for the audience that GNOME developers are targeting is "lowest common denominator".

It's the same problem with all excessively friendly interfaces, great if you are a day one user (pretty rare on Linux), obstructive and shitty if you know what you're doing.

I know what I'm doing and generally like Gnome.

Me too. That being said, I no longer use it on any of my devices. I heartily disagree with their development roadmap and feel somewhat lost as a former GTK tinkerer.

I know what I'm doing and I have no idea how people can deal with gnome on a day to day basis. I can survive only with plugins and those break very often,sadly.

Unfortunately I'm too lazy to switch to KDE (way too much stuff is broken if you install it not from the start and I don't want to reinstall), so I stick to gnome on my work computer.

I really, really appreciated KDE customization and power user options (hidden but there). It is messy and the UI is worse at times, but it's way ahead.

Thing is, people who are actually using Linux are almost exclusively tech people.

Well, this is a very strong and wrong assumption. There are ordinary people who are using Linux because of various reasons (my dad being one of them), and we want more people to use Linux, too.

If we continue to cater to only technically inclined people, we have no right to criticize Linux for being for the knowledgeable people only. If we want to attract more users from a more diverse community, we need to make some changes to user experience.

There is no buts or ifs. There are plenty of desktop environments. Technically inclined people can tinker with gconf, or install something different (KDE, E17, or any of the TWMs).

Sure, but you don't ignore your core audience to attract other users.

Valve built the Steam Deck knowing very well that their core users will be PC gamers and not console gamers. The steam deck is made as open as a pc, with functionality to jump back-and-forth between that and a pc (dynamic cloud sync).

Console gamers will come, but you don't ignore the people that are at the core of your business.

What do you mean as you recall? Did you follow the project updates on their issue and bug tracker? If you're not happy with it you know you can fork it and create your own derivative, right? Oh, so you just like to complain about how people spend their free time and want them to work for you for free?

the huge silent majority does not use Gnome.

It should be obvious that I'm referring to the huge silent majority of GNOME users.

> change shit for sake of changing shit...

While I'm a die-hard KDE user, I like how GNOME experiments with new ways of evolving the desktop paradigm and workflow attached to that.

Yes, they remove a lot of settings, and have a binary format for storing settings (and I don't like these design decisions), but it looks that they're becoming a very good DE for non-technical Linux user.

If any Linux desktop environment had 5% of this inconsistency, they would be battered to hell and back. Today, thanks to efforts of KDE and GNOME, even Qt and GTK apps can be rendered almost identically.

One might not like the direction of a particular DE, but I think we can agree that they're putting a lot of work towards a better, more usable desktop experience (and, I had my fair share of 3rd degree burns during GNOME3's teething as a developer).

AFAIK, GNOME 2.0 and KDE 3.5.x is still maintained as independent, different projects now, too.

GNOME3 was released in 2011, and around then, KDE did the same major overhall. I haven't seen too many major changes in the overall approach to the UI either has taken since then. Probably the most dramatic was the GTK4 update, which took quite a while.

> KDE did the same major overhall

The difference between GNOME and KDE's major overhauls is that KDE didn't get rid of all of their customization options in theirs.

I'm not complaining about the visual appeal of the UIs, I think they look great. I think MacOS is a good example of iterating on your UI experience and improving it, but not changing it to the point where half your OS ends up looking out of place due to tiny inconsistencies like the colour of titlebars or because the entire style of your OS keeps changing upon every new version.

Imagine if the next version of MacOS had square icons for close/minimise/maximise and to update your app to use that new style, you had to switch UI frameworks. Then you'd end up with 2 different styles of apps on your system because not every app out there made the switch, and one would now look very out of place. That's the sort of thing Windows seems to do every major release.

Setup.exe was installshield, not MS. Back then MS was still pushing .cab files

In fairness, MSIX is very different to MSI and ClickOnce was primarily a way to bootstrap MSIs from the web.

MSI (long since deprecated) is essentially an ad-hoc relational database serialized to a file with embedded blobs that tells a generic engine how to install files and update the registry. It was written for Office in the 90s and was therefore dominated by the retail model of physically shipping CDs.

MSIX is a totally different beast. It's more like a package for Linux. The format is a signed zip file with some embedded XML files. One of them is a "block map", which is basically an index into the zip data by chunk hash. Packages are installed to immutable directories, which lets Windows optimize out the download of data it already has on disk by copying from other packages or even just hard linking files together. Delta updates thus come for free (albeit not as powerful as diff based schemes when inserting data into the middle of a file). Another XML file declares how the app should be integrated into the OS. The old MSI/EXE model of manually patching and unpatching the registry and filesystem to do integration is gone here; for example, if you want to register a CLI command then that's an XML tag, if you want a file association or URL handler, that's a bit more XML. Windows takes care of wiring everything up and removing it on uninstall.

Most importantly, MSIX takes care of online updates. MSI never did this. You can register a URL for a package that points to yet another XML file, and Windows will download deltas and apply them in the background even if the app isn't running (a la Chrome).

So Microsoft's packaging tech hasn't churned that much. There were CABs from the Win3.1 days, then later MSI from the late 90s, and starting in Windows 10-ish timeframe MSIX. All of these are very different technologies.

One of the nice things about MSIX is that it's feasible to create them from other platforms, because although Microsoft's tools are Windows specific the format is simple enough to reimplement. Not simple - the way they compute the block map and signature data effectively requires you to write your own ZIP library to create them - but it can be done and that's why the new Conveyor tool [1] is able to create Windows self-updating desktop apps from Linux and macOS. If you have a pre-compiled runtime like Electron or the JVM then you can push out updates with one command from your Mac/Linux dev laptop, it's no harder than publishing a static website by rendering Markdown to HTML, and that makes it feasible to develop quick lightweight desktop apps in a convenient manner. With the old MSI or InstallShield tech it would have been much harder to create a cross platform tool like Conveyor.

[1] https://hydraulic.software/ (it can also do Linux and macOS apps from Windows, but those are a bit easier)

Why are they so into XML? Move on to json or yaml please

I think it's driven by a desire for strict validation. They provide XSD schemas and use them internally. Conveyor uses them too which not only helps catch internal bugs, it means if you provide a snippet of XML to do OS integrations the tool doesn't support yet then you still get good error messages at package build time telling you what you did wrong.

There are similar schema languages for JSON these days, but without any equivalent to namespaces. Microsoft uses versioned namespaces heavily in the AppX Manifest. It's got a bit crazy, a typical manifest might have 10 different xmlns declarations, but it means that if you mis-name an element or (more likely) put it in the wrong place that won't be silently ignored, it'll trigger a validation error. To get that you need to able to assign each element to a specific fixed schema and then compose them. If you just have a single schema and evolve it without any concept of namespaces, old software can't tell the difference between a mistake and a new extension from the future.

That seems like change for change's sake. XML is fine for stuff that's machine generated. I doubt anyone is hand-editing MSIX installers.

If it is not hand-edited, why isn't it binary?

Microsoft don't have any generically extensible binary format that they use consistently, like Google does with protobufs. Besides, XML isn't so bad.

Look at the alternative: Apple went with a generic binary config format for macOS (binary plists) but then introduced an XML version anyway. As an industry we've never got any good at managing the dichotomy between efficient-for-machines binary formats and efficient-for-humans text formats.

Probably simply because every version of Windows already has MSXML.DLL so your project gets it "for free".

MSIX is interesting but effectively unusable outside the Store (I spent a few months of my life trying to do that at $PREVIOUS_JOB). Installation will fail on a high percentage of machines, and you'll mostly be out of luck. There's a reason nobody at Microsoft uses it for installation outside the Store (Office did for a while but they gave up).

There are some bad bugs in older Windows versions, but we were always able to diagnose and work around them. It's part of the value Conveyor provides. We have it working now and the results are pretty good: fast installs and uninstalls (as long as there isn't a lot of latency to the web server), especially if you already have the files locally, background or check-on-start updates, management from the CLI, group policy, MSIX Hero and so on.

The alternatives are also not that great. I looked at many. Some are buggy, some are abandoned, some require complex server-side logic etc. The situation on Windows is far from ideal; it speaks to the general neglect of the platform. Nonetheless with a tool that works around or 'polyfills' issues MSIX can work well.

> MSI (long since deprecated)

Is it really deprecated? Isn't MSI still the only installer type directly supported by Group Policy? My company had an enterprise customer request an MSI for that reason.

MSIX supports group policy and other admin features:

https://learn.microsoft.com/en-us/windows/msix/group-policy-...

MSI isn't being developed any further and according to MS, the MSIX format is their "deployment technology moving forward".

https://mcpmag.com/articles/2018/08/09/microsoft-msix-replac...

MSIX is relatively new. The customers who requested an MSI may simply not know about it.

In my experience MSIX is the typical MS Windows project where it sounds really cool and looks well documented and supported until you actually try to use it. If you're on the beaten path, like a mobile app port for the windows store, it's probably fine. But if you're trying to do anything out of the ordinary you have to start doing Microsoft archaeology to figure out why something doesn't work.

For example certain build configurations would cause the runtime runtime to be somehow slightly different from the build runtime and it would trigger control flow integrity to immediately kill the app on startup which was very difficult to debug.

Also from documentation it looks like it's possible to install a background service and communicate with it over a named pipe from another application in the same package but in practice I don't think it's actually possible, even in a full trust app.

I think the goals of MSIX and the App SDK are good and I applaud them trying to make it flexible to support every kind of app, it just hasn't had the time or resources put in to be really worthwhile over just using NSIS at present.

Problems with CFI aren't related to the packaging mechanism though. Mismatches between DLLs have been an issue with Windows for a long time and the solution is usually to bundle the versions you need. Not sure about the background service thing, we haven't tried that.

I'd say that Windows in general is disappointingly buggy but it's been that way for a very long time, I remember having to work around bad Windows bugs in the 95 and XP days too. It just comes with the territory. We use MSIX as raw material and either work around bugs or reimplement features as necessary. The results seem to work fairly well. MSIX also has the advantage of being maintained and general purpose, which sounds basic, but a fair number of the competitors aren't.

Reply on news.ycombinator.com