In theory yes. In practice, not really. There are a few blocking problems with respect to making LSB RPMs (if you are doing it to make things easier for the user and not for regulatory compliance or whatever):
Out of the box none of the major desktop distros are LSB compliant as they don't provide the LSB release file or linker symlink. At minimum therefore the user has to locate and install the right LSB base RPM for their system
LSB doesn't formally specify much stuff. Hardly anything in fact. C++ is out as various distributions (like Red Hat) decided they didn't want to standardise on a buggy g++ ABI, instead they wanted to break the C++ ABI yet again and get a bit closer to Itanium compliance. Desktop toolkits are out, unless you want to statically link the whole thing which whacks up theming and makes your memory footprint huge. Pretty much any other library is out as it's not included.
You need to use their build environment. Not such a big deal this one but last time I tried it (a long time ago I must admit) most software didn't compile under it.
Because the LSB is currently so small it's pretty useless for desktop Linux software developers, and it doesn't attempt to overrule upstream goofs like NPTL so it would not prevent things like the Loki Games breakages.
I think it's useful mostly for big-iron server vendors right now - programs that don't need much stuff from the OS but must be certified.
Actually I think you could argue that old versions of Windows and Office are Microsofts biggest competitor. KDE and GNOME may well be what eventually fills the void but I wouldn't be surprised if Linux takes over partly because Microsoft have been weakened by the increasing difficulty of selling upgrades to people who already own software which does, basically, work.
You were probably installing Gaim and had the wrong version of GnuTLS. Yes? That's a known problem, the Gaim developers are aware of it, and will probably be autopackaging GnuTLS themselves at some point and/or changing Gaim so it can use multiple major versions of GnuTLS. SSL in general is just a big pain and Gaim has an entire FAQ devoted to it.
Also in future we want autopackage to know how to use apt to install things it needs, as well as being able to resolve dependencies from other autopackages.
Autopackage is not a magic pill that makes everything better. It is a tool that combined with changes to software and new methods of community development can significantly ease the pain of installing unsupported software into a distribution.
autopackage bears no resemblence to epm, or any other "package manager" we're aware of. I suggest you read about it more carefully, as otherwise you'll jump to incorrect conclusions. It is not "just another file format" either, in fact the contents of.package files are implementation-defined and subject to change without notice.
It is best described as a hybrid between NSIS/Loki Setup type installers, and package managers such as dpkg and RPM. Autopackages are programs that understand the quirks of various distributions, and which contain binaries compiled in such a manner that they are binary-portable across a wide range of Linux systems. When run they will integrate that software with the users system in the tightest way possible. They understand dependencies and dependency checking, and can resolve missing dependencies. They understand 4 or 5 different menu systems and can place items in the menus for all of them. It allows you to install that software to your home directory. It provides both GTK and Qt based uninstallation tools. It has been designed with end-user usability in mind from the ground up.
It is a real, useful piece of software that exists today and is not a theoretical program that works perfectly in a theoretical world. It does not require you to use it for all your software. It does not require special setup. It does not require distributions to support it. It does not need you to be using the "right" Linux system to work. Naturally, it is not a magic pill that works 100% of the time either, but that was a conscious design tradeoff we made at the time.
In other words, it's a program designed specifically for the situation the Linux community currently finds itself in. Please show me another program that meets these design criteria. The closest I'm aware of is ZeroInstall which is nonetheless very different.
OK, any modern OS uses shared libraries and this is a good thing. Let's take that as axiomatic. There are a few people around who believe that shared libraries are inherantly evil and should go, but they apparently don't know anything about operating system engineering. Clearly if they did, they would not say that.
So like any powerful tool, there is a tendency to overuse it, or use it where it's not appropriate. Without shared libraries we could not have systems like Windows XP, Linux or MacOS X because no machine today would have enough resources to do it at an acceptable speed. But nonetheless, it's undeniable that managing them correctly turned out to be significantly harder than expected for all operating system developers.
Linux treats software as a set of nodes on a graph, with each node representing one small piece of software. Dependency resolvers like apt treat every node as of equal importance, there is no distinction between system level packages and third party packages. They work by doing a topological sort on the dependency graph (amongst other things). This works well as long as the software has representation in the graph. If it does not then things start to break.
Windows treats software as falling into two camps: system level software and third party software. However the line is often blurred, because Microsoft distribute upgrades like DCOM98 and DirectX 9 as installers that can be distributed with third party software. These updates then appear in the Add/Remove Programs window. The advantage is that people get insane value for money out of a Windows purchase: you're still able to play games like Pirates! which needs DX9 on Windows 98, an OS that is now seven years old. The disadvantage is that this process was never thought through or managed and the inevitable result was "DLL Hell".
MacOS X is simply a more extreme version of Windows. There's a clear cut distinction between system level software and third party software. While third parties can ship newer frameworks inside themselves (Windows/Linux devs can do this too but generally don't...) this facility is hardly used. Instead Mac users have to put up with a crazily fast release cycle: try finding MacOS X apps that still work on the original 10.0 release - it's not actually that old, but there are almost none. In fact many programs require the very latest release in order to function correctly. Remember that each major version upgrade is $120!
So all these platforms suffer "dependency hell" though it comes in different forms and is known by different names. Should Linux change?
Yes... yes I think it should. The situation where non distro-provided software requires Herculean efforts to install is simply ludicrous, as distributor packaging has been empirically shown to have serious scalability problems. Right now projects like autopackage simply attack the problem with code - the idea being that by providing a new system that closely integrates with the host system (apt/yum/emerge/etc) but is nonetheless specifically designed for third party software, we can begin separating the graphs and so provide a stable platform on which Linux developers can build. It's only one part of the puzzle and is currently woefully incomplete (for instance, it can't resolve dependencies from Debians apt yet).
But long term the direction we must go in is a hybrid - a stable, well specified base platform which is documented and predictable, with powerful dep resolver technologies to allow us the flexibility to quickly deploy new code without compromising system efficiency. With it must come a realisation that sometimes static linking is OK, even necessary if we are to achieve that goal. If dependencies are causing your users more pain than gain, don't use them
The paths embedded in binaries are deadly. The autopackage folks are not the only ones who have approached this, but I'm not sure they realize it. They're following the same approaches and will hit the same walls.
The right way to solve this is by providing binary relocatability support in core libraries and small utilility files that can be statically linked. This is what binreloc is, you can find out more at the autopackage homepage, and it's designed to be trivial to drop into pre-existing software. It requires patching the code, but it takes all of half an hour to do even complex apps like Gaim and Inkscape. The fact that it requires patching isn't a problem, as autopackage is designed to be used by upstream developers with their full knowledge and consent.
Of course the idl compilers are different so they are not compatible at that level, but once compiled, a DCE rcp client/server can talk to a DCOM client/server, assuming you are not trying to use any of the security built into the DCE-RPC
That's not entirely true. DCOM is layered on DCE-RPC yes, but actually activating and programming a remote DCOM object is a lot more work than just using the RPC APIs. DCOM adds some kind of "object oriented"ness to it so you'd have to be able to understand OBJREFS and such. Implementing DCOM on Unix is underway in the Samba4 and Wine projects, but DCE-RPC is only one half of the puzzle.
Ah, I didn't say multiple competitors meant a market was broken, I said that given the operating systems (platforms) market natural tendency towards monopoly we're best to stick with Microsoft for now as interop with them is well understood
So just by Apple existing it creates "very unstable economic scenario" and there has to be a monopoly in operating systems, so it might as well be MS?
Pretty much. Obviously Apple don't have much economic impact at the moment.
Now does this same logic apply to word processors? Does a file format create a network effect which will create a natural monopoly or a "very unstable economic scenario" if more than one competitor exists?
The same effects are at work but writing a word processor compatible with the competition takes such a tiny fraction of the effort building a complete operating system+ecosystem does that they are much weaker. But yes, one reason that MS Office is so dominant is that unbending the market (by being fully compatible) is so very difficult.
Does this apply to the ipod?
No because the iPod is not a platform, so it's not affected by these free market distortions that operating systems are. You could argue that artificially tying the iTunes music store to it has the same effect though. Generally tying two products together in the real world is much harder, ie Gillette cannot use encryption and lawsuits to stop a competitor making razor blades for its razors. Where it has happened typically there have attempts to stop it.
What about platforms on platforms (ie java, web applications) do these rules apply here too?
Java, yes, web applications: a bit. Implementing a web browser is less effort than cloning the entire Java platform but it's still a significant amount of effort. But it's doable in a sensible amount of time if you're really really interested in doing so (though how you make money off that is anybodies guess).
Another example of a platform would be Sky TV though most people don't use the word "platform" to describe it. But do you choose Sky TV because of the inherant greatness of Sky, or because it has the channels and programs you want to watch? The channels built upon the Sky content distribution platform, in the same way that software vendors build upon Windows.
OK, look. Classical capitalist economics is based on the concept of the free market, which is supposed to ensure competition and therefore make everything better, more efficient etc. Everybody knows this, it's basic stuff. The free market makes some simplifying assumptions, eg that of the "perfectly informed consumer" which means that people always buy products based on having all the information available. This is also obvious: if there are two products, A and B and product A is expensive, unreliable, disliked and B is wonderful, innovative and cheap but everybody buys A because they don't know about B, the free market isn't working and things aren't getting better.
So the free market and the perfectly informed consumer are fairly obviously platonic ideals never actually reached but you can get close, that's why we have product reviews and laws against anti-competitive behaviour. Because really the the free market is not magically robust against human greed and manipulation so it requires protection and control to ensure it does its job. That's why pure capitalism is essentially equivalent to anarchy.
"Platforms" like Windows or MacOS/X, or yes MS Office or Java too, bend the free market and they do so by affecting the perfectly informed consumer part. OK so you may know about MacOS/X but do you use it? If you don't why is that? Is it because you want to run games that only come out for Windows? Is it because you use an application that isn't available on the Mac? Is it because you want to use what you use at work (very common for less technically oriented individuals) and work can't use Macs because they have a million custom programs written in Visual Basic and Access, and an intranet full of IE specific JavaScript?
The problem with that situation is we've been there before, eg in the late 80s/early nineties with a mix of different hardware/software platforms (at least this was true in the UK). The problem is that due to the nature of platform lockin, it's a very unstable economic scenario.
Once one player gets ahead of the others by even a relatively small amount (for instance, by buying up a new "killer app" and killing off the competing ports) the playing field tips in their favour which in turn makes them stronger allowing them to tip the playing field even more. The natural end result is monopoly, which is exactly what we have now.
I remember not that long ago really there was a great diversity of computers in the UK: there were DOS based PCs, Macs, Acorn RISC machines, Commodores, and a few others I forgot about. Today there are only Windows PCs (Apple has even tinier market share here than in the states). Once Microsoft got ahead by both fair means and foul the result was inevitable.
So no, while it may seem intuitively obvious I don't believe a 30/30/30 split in the OS marketplace would be a good thing, it might be a stable combination in any other market which actually plays by the normal rules of capitalism, but the OS market does not and what is stable for eg bakers is a knife-edge for platform owners.
You've clearly never tried to buy a wireless that is supported by Linux: hint, you basically have to buy off eBay and it's that way because of Linus' stance on module interface stability.
I didn't notice MS being in trouble. I noticed them having lots of users, whereas OpenBSD has comparitively few.
A usable system that does what its owners need will win over a secure system every time. It's simple logic: would you, on the grounds that it's better to be safe than sorry, drive a car that self-destructed every few months because it thought it was being drive by a thief? No? Well, Joe User is in the same boat with computers, a secure but hard-to-use or incompatible OS is about as useful as a painting on the wall: nice to admire but not something you turn to when work has to be done.
Hah, if my grandmas actually used computers at all (they don't) I wouldn't want them to be running a system where apps might disappear at a moments notice because they contravened the PaX developers idea of what secure code is. PaX breaks/changes some pretty core APIs, and while you can disable it on a per-process basis how many people will be able to diagnose that? And if they can, what's the point of security system you usually switch off when it triggers - warning fatigue anybody?
Let's ignore the fact that the PaX developers idea of what is buggy/broken/insecure code is by no means widely accepted, and is quite a controversial debate all in itself.
Now don't get me wrong, PaX has its place, but that place isn't on my hypothetical relatives desktop at least not in its current form. I'll go with a weaker form of security that has fewer false positives and that doesn't require me to explain that they lost their work when they decided to use feature XYZ of their word processor for their own good....
I seem to recall seeing proof of concept exploits out there for sure, in fact it was so easy there wasn't really any need for one. So on what basis are you claiming nobody ever got exploited? Just because you don't see it happening doesn't mean it didn't happen, that's 2 year old thinking.
Oh by the way, this is going to sound stupid but are you Chris Jones originally from Macclesfield? I couldn't help but notice you had a friend called "Jonathon Perkins", seemed a bit of a co-incidence...
The bug mentioned in the LWN article was apparently not treated as serious by Andrew Morton and other developers on the grounds that there are far easier ways to DoS a system without using kernel exploits like that one. I don't know whether that's good or bad, but from debating things with various PaX guys myself I know they have a rather extreme approach to security (not something I'd ever give my grandma...)
That's not true at all, try creating a.desktop file that looks like a Word document but which actually runs a program then attaching it to an email in Evolution.
A rather more accessible text if you're interested in a clear and precise description of How Money Works is The future of money by Bernard Lietaer. It's not a textbook, it's written for the layman and it also includes various social theories of the author which if you're in it purely for economic insight can be ignored. But this has a wonderful appendix which takes you through the basics of money like "where does it come from", "what is fractional reserve banking", "why does debt power our economy" etc in a clear and accessible way illustrated by stories and so on.
So I'm not sure it counts as a "profound text", and it's not an economic bible but it is good.
Comparing SDL to DirectX is like comparing apples to a Christmas dinner. SDL+OpenGL covers only a tiny subset of its functionality. Don't get me wrong, what's there is good. But it's not DX.
"Restarting the GUI" means killing every GUI app, so the user loses all their work. It's functionally equivalent to rebooting.
You're also assuming an IT helpdesk has the time and patience to ssh in and figure out which app (if any) has locked the X server every time it hangs. Not going to happen.
Slashdot Mirror
Because the LSB is currently so small it's pretty useless for desktop Linux software developers, and it doesn't attempt to overrule upstream goofs like NPTL so it would not prevent things like the Loki Games breakages.
I think it's useful mostly for big-iron server vendors right now - programs that don't need much stuff from the OS but must be certified.
Actually I think you could argue that old versions of Windows and Office are Microsofts biggest competitor. KDE and GNOME may well be what eventually fills the void but I wouldn't be surprised if Linux takes over partly because Microsoft have been weakened by the increasing difficulty of selling upgrades to people who already own software which does, basically, work.
Also in future we want autopackage to know how to use apt to install things it needs, as well as being able to resolve dependencies from other autopackages.
Autopackage is not a magic pill that makes everything better. It is a tool that combined with changes to software and new methods of community development can significantly ease the pain of installing unsupported software into a distribution.
It is best described as a hybrid between NSIS/Loki Setup type installers, and package managers such as dpkg and RPM. Autopackages are programs that understand the quirks of various distributions, and which contain binaries compiled in such a manner that they are binary-portable across a wide range of Linux systems. When run they will integrate that software with the users system in the tightest way possible. They understand dependencies and dependency checking, and can resolve missing dependencies. They understand 4 or 5 different menu systems and can place items in the menus for all of them. It allows you to install that software to your home directory. It provides both GTK and Qt based uninstallation tools. It has been designed with end-user usability in mind from the ground up.
It is a real, useful piece of software that exists today and is not a theoretical program that works perfectly in a theoretical world. It does not require you to use it for all your software. It does not require special setup. It does not require distributions to support it. It does not need you to be using the "right" Linux system to work. Naturally, it is not a magic pill that works 100% of the time either, but that was a conscious design tradeoff we made at the time.
In other words, it's a program designed specifically for the situation the Linux community currently finds itself in. Please show me another program that meets these design criteria. The closest I'm aware of is ZeroInstall which is nonetheless very different.
So like any powerful tool, there is a tendency to overuse it, or use it where it's not appropriate. Without shared libraries we could not have systems like Windows XP, Linux or MacOS X because no machine today would have enough resources to do it at an acceptable speed. But nonetheless, it's undeniable that managing them correctly turned out to be significantly harder than expected for all operating system developers.
Linux treats software as a set of nodes on a graph, with each node representing one small piece of software. Dependency resolvers like apt treat every node as of equal importance, there is no distinction between system level packages and third party packages. They work by doing a topological sort on the dependency graph (amongst other things). This works well as long as the software has representation in the graph. If it does not then things start to break.
Windows treats software as falling into two camps: system level software and third party software. However the line is often blurred, because Microsoft distribute upgrades like DCOM98 and DirectX 9 as installers that can be distributed with third party software. These updates then appear in the Add/Remove Programs window. The advantage is that people get insane value for money out of a Windows purchase: you're still able to play games like Pirates! which needs DX9 on Windows 98, an OS that is now seven years old. The disadvantage is that this process was never thought through or managed and the inevitable result was "DLL Hell".
MacOS X is simply a more extreme version of Windows. There's a clear cut distinction between system level software and third party software. While third parties can ship newer frameworks inside themselves (Windows/Linux devs can do this too but generally don't ...) this facility is hardly used. Instead Mac users have to put up with a crazily fast release cycle: try finding MacOS X apps that still work on the original 10.0 release - it's not actually that old, but there are almost none. In fact many programs require the very latest release in order to function correctly. Remember that each major version upgrade is $120!
So all these platforms suffer "dependency hell" though it comes in different forms and is known by different names. Should Linux change?
Yes ... yes I think it should. The situation where non distro-provided software requires Herculean efforts to install is simply ludicrous, as distributor packaging has been empirically shown to have serious scalability problems. Right now projects like autopackage simply attack the problem with code - the idea being that by providing a new system that closely integrates with the host system (apt/yum/emerge/etc) but is nonetheless specifically designed for third party software, we can begin separating the graphs and so provide a stable platform on which Linux developers can build. It's only one part of the puzzle and is currently woefully incomplete (for instance, it can't resolve dependencies from Debians apt yet).
But long term the direction we must go in is a hybrid - a stable, well specified base platform which is documented and predictable, with powerful dep resolver technologies to allow us the flexibility to quickly deploy new code without compromising system efficiency. With it must come a realisation that sometimes static linking is OK, even necessary if we are to achieve that goal. If dependencies are causing your users more pain than gain, don't use them
The right way to solve this is by providing binary relocatability support in core libraries and small utilility files that can be statically linked. This is what binreloc is, you can find out more at the autopackage homepage, and it's designed to be trivial to drop into pre-existing software. It requires patching the code, but it takes all of half an hour to do even complex apps like Gaim and Inkscape. The fact that it requires patching isn't a problem, as autopackage is designed to be used by upstream developers with their full knowledge and consent.
I'm not sure what your point is, amaroK is a KDE app ... with a K! Scribus is a Qt app not a KDE app, DigiKam is a KDE application with a K etc...
That's not entirely true. DCOM is layered on DCE-RPC yes, but actually activating and programming a remote DCOM object is a lot more work than just using the RPC APIs. DCOM adds some kind of "object oriented"ness to it so you'd have to be able to understand OBJREFS and such. Implementing DCOM on Unix is underway in the Samba4 and Wine projects, but DCE-RPC is only one half of the puzzle.
Ah, I didn't say multiple competitors meant a market was broken, I said that given the operating systems (platforms) market natural tendency towards monopoly we're best to stick with Microsoft for now as interop with them is well understood
Pretty much. Obviously Apple don't have much economic impact at the moment.
The same effects are at work but writing a word processor compatible with the competition takes such a tiny fraction of the effort building a complete operating system+ecosystem does that they are much weaker. But yes, one reason that MS Office is so dominant is that unbending the market (by being fully compatible) is so very difficult.
No because the iPod is not a platform, so it's not affected by these free market distortions that operating systems are. You could argue that artificially tying the iTunes music store to it has the same effect though. Generally tying two products together in the real world is much harder, ie Gillette cannot use encryption and lawsuits to stop a competitor making razor blades for its razors. Where it has happened typically there have attempts to stop it.
Java, yes, web applications: a bit. Implementing a web browser is less effort than cloning the entire Java platform but it's still a significant amount of effort. But it's doable in a sensible amount of time if you're really really interested in doing so (though how you make money off that is anybodies guess).
Another example of a platform would be Sky TV though most people don't use the word "platform" to describe it. But do you choose Sky TV because of the inherant greatness of Sky, or because it has the channels and programs you want to watch? The channels built upon the Sky content distribution platform, in the same way that software vendors build upon Windows.
OK, look. Classical capitalist economics is based on the concept of the free market, which is supposed to ensure competition and therefore make everything better, more efficient etc. Everybody knows this, it's basic stuff. The free market makes some simplifying assumptions, eg that of the "perfectly informed consumer" which means that people always buy products based on having all the information available. This is also obvious: if there are two products, A and B and product A is expensive, unreliable, disliked and B is wonderful, innovative and cheap but everybody buys A because they don't know about B, the free market isn't working and things aren't getting better.
So the free market and the perfectly informed consumer are fairly obviously platonic ideals never actually reached but you can get close, that's why we have product reviews and laws against anti-competitive behaviour. Because really the the free market is not magically robust against human greed and manipulation so it requires protection and control to ensure it does its job. That's why pure capitalism is essentially equivalent to anarchy.
"Platforms" like Windows or MacOS/X, or yes MS Office or Java too, bend the free market and they do so by affecting the perfectly informed consumer part. OK so you may know about MacOS/X but do you use it? If you don't why is that? Is it because you want to run games that only come out for Windows? Is it because you use an application that isn't available on the Mac? Is it because you want to use what you use at work (very common for less technically oriented individuals) and work can't use Macs because they have a million custom programs written in Visual Basic and Access, and an intranet full of IE specific JavaScript?
In other words the OS lockin we're all so familia
Once one player gets ahead of the others by even a relatively small amount (for instance, by buying up a new "killer app" and killing off the competing ports) the playing field tips in their favour which in turn makes them stronger allowing them to tip the playing field even more. The natural end result is monopoly, which is exactly what we have now.
I remember not that long ago really there was a great diversity of computers in the UK: there were DOS based PCs, Macs, Acorn RISC machines, Commodores, and a few others I forgot about. Today there are only Windows PCs (Apple has even tinier market share here than in the states). Once Microsoft got ahead by both fair means and foul the result was inevitable.
So no, while it may seem intuitively obvious I don't believe a 30/30/30 split in the OS marketplace would be a good thing, it might be a stable combination in any other market which actually plays by the normal rules of capitalism, but the OS market does not and what is stable for eg bakers is a knife-edge for platform owners.
That's a good thing because .... ?
If you think a powerful Apple would be any less evil than a powerful Microsoft is, you need to step outside the RDF for a bit
You've clearly never tried to buy a wireless that is supported by Linux: hint, you basically have to buy off eBay and it's that way because of Linus' stance on module interface stability.
A usable system that does what its owners need will win over a secure system every time. It's simple logic: would you, on the grounds that it's better to be safe than sorry, drive a car that self-destructed every few months because it thought it was being drive by a thief? No? Well, Joe User is in the same boat with computers, a secure but hard-to-use or incompatible OS is about as useful as a painting on the wall: nice to admire but not something you turn to when work has to be done.
It was fixed in Linus' upstream kernel either yesterday or the day before, I forget which.
The "easy way" in this case is just allocating lots of memory pushing the box into swap hell. Hardly a secret.
Let's ignore the fact that the PaX developers idea of what is buggy/broken/insecure code is by no means widely accepted, and is quite a controversial debate all in itself.
Now don't get me wrong, PaX has its place, but that place isn't on my hypothetical relatives desktop at least not in its current form. I'll go with a weaker form of security that has fewer false positives and that doesn't require me to explain that they lost their work when they decided to use feature XYZ of their word processor for their own good ....
I seem to recall seeing proof of concept exploits out there for sure, in fact it was so easy there wasn't really any need for one. So on what basis are you claiming nobody ever got exploited? Just because you don't see it happening doesn't mean it didn't happen, that's 2 year old thinking.
Oh by the way, this is going to sound stupid but are you Chris Jones originally from Macclesfield? I couldn't help but notice you had a friend called "Jonathon Perkins", seemed a bit of a co-incidence ...
The bug mentioned in the LWN article was apparently not treated as serious by Andrew Morton and other developers on the grounds that there are far easier ways to DoS a system without using kernel exploits like that one. I don't know whether that's good or bad, but from debating things with various PaX guys myself I know they have a rather extreme approach to security (not something I'd ever give my grandma ...)
Oh, wait ... they have.
That's not true at all, try creating a .desktop file that looks like a Word document but which actually runs a program then attaching it to an email in Evolution.
So I'm not sure it counts as a "profound text", and it's not an economic bible but it is good.
Comparing SDL to DirectX is like comparing apples to a Christmas dinner. SDL+OpenGL covers only a tiny subset of its functionality. Don't get me wrong, what's there is good. But it's not DX.
You're also assuming an IT helpdesk has the time and patience to ssh in and figure out which app (if any) has locked the X server every time it hangs. Not going to happen.