Ah, so you're the one person who's responsible for messing up my GNOME! Me and my, um 'attorneys', Fingers and GBH, would like a word wit' ye, in this back alley...
Re:What problem does Gnome 3 solve?
on
GNOME 3 Released
·
· Score: 4, Interesting
In all honesty, Windows 95's interface was terrible. It managed to be a step back from Windows 3 in many respects.
Interesting. I have a contrary opinion: to me, Windows 95 was the high-water mark of Microsoft's interface design and got some things right which everyone else - 2000s-era Microsoft included - have been strugging to even understand since.
Granted, the cascading Start Menu was horrible. But that can be fixed. The underlying "a shortcut on the menu is just a desktop shortcut inside a Menu folder" architecture was a stroke of utter genius, one GNOME completely failed to get. They had to create two incompatible kinds of launchers, and make it near-impossible to edit menus, or to drag one to the other. Why? The Win 95 way was so perfect.
The taskbar, too, is something that was brilliant compared to the Dock or anything else: an area that could show you at a glance where all your currently running stuff is. Yes, it's simplistic, and needs to be expanded - but the basic idea of dividing the screen into separate permanently-there areas, one which gives you an overview, one which gives you a closeup, was awesome. The big win of the Start Button is that (unless you really mess with things) it's always there in a known location. Same principle as Apple's menu (possibly they couldn't just do that because of look-and-feel patents? they were still a big deal in the mid-90s).
What I'd like is an interface which lets me extend this principle, to let me create user-defined fixed 'trays' in various parts of my desktop where I can guarantee that windows can't spill out of. For a while I thought Gnome's panels were going to be this, and I loved having one at the top and one at the bottom, one for menu and one for taskbar, but knowing that under the hood they were just identical instances of Panel.
I think the ultimate desktop still will be document-oriented - something like a Zoomable User Interface - rather than application-oriented, but we seem to have abandoned the quest for this and keep iterating on tiny visual variations of a half-finished underlying architecture, but now with the added pain that the user can't change the visual look and feel anymore. This seems like going in precisely the wrong direction. I'm at a loss to understand why this is. If we'd invested half the effort that's gone into force-feeding rigid visual look-and-feels onto an unwilling userbase, instead into creating an underlying architecture that seriously splits the look and feel from the underlying data and lets the userbase create and remix their own 'look' while the application developers can focus on the data processing - wouldn't we be a lot further ahead?
tldr: I don't want application designers telling me how to organise my desktop. I want them to give me the tools that let me organise my desktop however I want. But they're not. Why?
He's referring to Helium 3 which is thought to be abundant on the moon and very rare here. Great for fusion power.
Yes, and the Cavorite deposits will also be very useful once we've developed a practical antigravity drive, which will be done about three decades before fusion achieves breakeven.
When I look up and see the Moon, I see a large amount of energy that soon could be within Humanities reach.
You mean if we deorbit it? Yeeees... that would certainly impart a large amount of energy very quickly. Might be a bit difficult to convert into anything except thermal and acoustic, but that's acceptable if we aim it at an uninhabited continent. Certainly worth investigating!
Sure, but if you inhale or eat any dust, you have a distance of 0. Extra special bonus if it's iodine or cesium or strontium, it gets incorporated into your body tissues or bones. Mmm crispy fried thyroid with a side of leukemia.
All interfaces can be done by passing streams of data with minimal predefined formatting
I think your analysis of the problem agrees with mine. The brittleness of OO/component programming with strictly typed interfaces vs the freedom of Unix piping.
Text, though, doesn't seem to quite cut it for exchanging structured data. Could there be a sweet spot in between?
I've been toying with ideas for universal lightweight 'structured data' languages. What if we had something like a shell which exchanged something like JSON? (Not really JSON because it's not fully universal - you can't, eg, express dictionaries containing dictionaries as keys - but something like that). Could we invent a whole new approach to 'pipeable untyped OO'?
This is an idea which is germinating in my mind for a new structured data format - table expressions. Very much draft, but I'm wondering if you would have useful comments?
I don't think that's true. Once you have seen a command-line program, you have seen all of them (ok, 95% of them).
On the other hand, every GUI-based program is different. You can't use the knowledge you gained on Visual Studio to work with Eclipse.
Interesting you should say that, because precisely the opposite was true in the 1980s on the IBM PC and MS-DOS platform. We had a whole marketplace of application software - WordStar, WordPerfect Lotus 1-2-3, Microsoft Word for DOS, dBase II - all of which had completely different command keys. When GUIs came along, the first thing they did was standardise basic functions like menus, navigation, and system utilities like fonts and printing.
If you weren't there, you can't imagine how unutterably hideous it was for every word processor to have to install its own printer driver. Or the Lovecraftian gibberish that was WordPerfect's function key template overlays. It used all ten F-keys, plus Ctrl, Alt and Shift. Mortal mind could not remember them all. If you pressed 'F1' it was not help. If you pressed 'Escape', it repeated the next action.
But now - at least until the last few years, before Microsoft's 'Ribbon' and Apple's i-devices - you knew if it's a GUI, it'll have menus, the left one will be 'File' and the right one 'Help', you can get context menus with right-click...
Now Apple and Microsoft (and GNOME 3) are doing their best to throw away 30 years of standardisation, and that's going to be like the 80s babel all over again, for you youngsters who missed it. Have fun!
In short? A command line in the Unix sense is more flexible than a GUI in the Windows sense because in the Windows paradigm, there is no general graphical equivalent of a text editor. The closest equivalent is a graphical form builder as in Visual Studio, but you can't create, for example, a Powershell or VBScript file simply by dragging graphical components around. There's no inherent GUI reason why this should be the case and it would be super-neat if you could. But at the moment, you can't.
But even if you could create fully visual 'scripts' , a second way in which the command line is superior is that it is a 7-bit clean ASCII serial transport, which means that you can send a script through email, back it up securely, and transport it to other systems. GUI components are extremely tied to very specific OS and machine versions and do not transport or save well.
I believe this is a bad side-effect of the object-oriented programing philosophy that grew up alongside GUIs, which made opaqueness of implementation a religious tenet without realising that opaqueness prevents portability. OOP's encapsulation and data hiding rules almost deliberately reject portability, which is ironic because that's the opposite of OOP's proclaimed intentions.
If a standardised 7-bit clean text serialisation were created for every visual object on a Windows-like system - preferably one which was also cleanly human-editable as text - then we'd have something. But I think you'd have to deliberately break some deeply treasured OOP thinking to get there.
GUIs are appropriate to non-expert systems where functionality must be patently clear.
No, restricted interfaces are appropriate to non-expert systems. There's no a priori reason why a GUI must be a restricted interface, or a CLI should be a widely open one. This is the sort of muddled thinking which frustrates me.
In the days before GUIs, we implemented restricted interfaces either using 'menu' systems, or special-purpose command languages with a 'help' command which listed the available commands. Both are very simple to use. In fact, most GUIs can be seen as just graphical menus - and there's really no reason why an obscure icon should be more immediately understandable than a line of text describing the function. Often the reverse is true - this is why I like tooltips (explanatory text) and dislike Microsoft's 'ribbon' - opaque icons with no text.
But GUIs for advanced applications like 3D editors are very complicated and are not for beginners. We could make GUIs for the whole system which are just as powerful as CLIs (for example, you could build a 'command graph' rather than a 'command line' out of icons rather than names of tools).
It's just that we haven't. For historical reasons, not logical ones. The result is a hybrid system which is not entirely logical.
It's a two-dimensional grid: restricted choice menus vs open modifyable generative system, and CLI vs GUI. We shouldn't conflate the two axes.
One thing our current GUIs lack is decent visual 'structured collection' conventions. It seems like it wouldn't necessarily be hard - a box for a collection, a line and arrow for a sequence - and then you could represent something like XML or any other structured-text format, including text-based programming languages, as a composite graphical construct. Then, if you could switch any subnode between text or graphical representations, and zoom in and out... wouldn't that be something?
Way back when Visual Basic first came out I was excited because I thought Microsoft was sensing this, and could give us access to the whole system in graphical form. But somehow it turned out not to be like that. Walls upon walls. VB vs C++, no way of graphically creating components themselves, lots of stuff with no visual representation, and rapidly evolving visual design languages in each new product line which kept destroying any hope for a universal visual language to emerge.
Squeak Smalltalk seems to be trying something similar. But it doesn't play well outside its own VM.
No, but it would be really nice if the diagram editor loaded and saved as a series of CLI instructions, so that you could back up your network configuration, and then, eg, email it to a hosting company and have them run it through a script that automatically creates a bunch of virtual machines that replicates that network.
If you like to go out to the woods, cut down a tree, rip it into boards, plain and sand them, then build a chair, sand and finish it... that's great. But I just want to read a book... and buying a $10 chair at walmart will work fine.
The problem is that with today's architectures, the difference is more between assembling a chair from bare pine logs with an adze which you ground yourself, vs having a magic nuclear-powered nanotech chair pop into existence in your house when you think the colour blue, but which comes in only one size and colour, is bolted to the floor, randomly reconfigures itself every year, and if you ever try to look inside without a billion dollars of lab equipment, you get radiation burns and the nearest closet turns into a rabid badger.
It would be nice to have something somewhere in between. Even nicer would be to be able to buy a set of tools and lumber, or a prebuilt pine-wood chair with full assembly diagrams, and be able to repair it as you like.
That's your opinion. I think the point the original poster is making (certainly the point I'd make) is that our interfaces should be agnostic as to whether a human or a decision-making algorithm is driving them.
Because otherwise, how are we going to take control of our workflow and delegate the automatable parts of it to automation, if the interfaces we use stubbornly insist that 'no, a human must be in the loop to do that!'
This attitude, which sadly is rife among GUI designers, is keeping us stuck in the dark ages. It fundamentally shouldn't matter if a human or a program is doin any job on your desktop. End of story. It's not the interface's job to decide. If a script can take a look at a JPEG, apply a beauty algorithm and decide to fudge the colour contrast and recrop - and if a human can look at that afterwards and decide that it's good and keep it - well, then that's editing, isn't it? But it's done by a partnership of human and machine, as it should be.
Don't force us to decide between human and machine for every job, and especially, as an application designer, don't impose your conception of what tasks should be done by which. As a user, closer to the coalface, I might well have a better idea. If your software gets in the way of my automation, it's wrong.
GUI = makes it easy to do one off tasks, because the interface can be made intuitive. CLI = makes it easy to do repetitive tasks, because they can be easily scripted.
That task split between GUI and CLI is exactly what I think went wrong when GUIs were first designed.
What we should have done was created a GUI which has exact formal one-for-one-correspondence with the underlying CLI, so that for any given task, you can use the interface of your choice that works for you - or create new graphical interfaces for the special custom jobs you end up doing multiple times.
And it wouldn't have been that hard to do. GUIs involve message passing, but we chose not to expose those messages as scriptable 'commands' at the same level as a CLI. We hid them and required C++ and other system/application languages to send those messages in full, then exposed a tiny fraction of them to various "scripting languages". But you can't write all applications in scripting languages, so it's a lossy conversion filter.
The result is, we've got at least three levels to our systems: a reasonably transparent 1960s-batch-system derived command/process/file based layer, an opaque 1980s Smalltalk-derived object/component layer, and finally combined applications/GUI/preference files launched by the 1960s layer which orchestrate the 1980s layer to do stuff. We can't use the 1960s layer (CLI) to do everything the 1980s layer (GUI plus services/components/DLLs) can do, because the 1960s layer has fundamental connection concepts like piping and "everything is a file which is an I/O stream" which simply don't exist in the 1980s "everything is an object" layer. It's impedance mismatch at the OS level.
The big problem with an impedance mismatch is that you can't solve it by adding more lossy-conversion layers. It can only be really "solved" by creating a new abstraction which has the features of both, but that seems impossible now that we have a huge weight of legacy code. I'd been hoping that Linux in the 2000s would give us some hope of breaking away from the Windows cruft and coming up with a simple unified desktop framework. But GNOME and KDE seem to have just fragmented the situation even more.
Wish I could see a plausible way out of this mess.
Slashdot Mirror
97 for me... and 98 before I switched my Windows desktop for it... but yes.
Come on, didn't the Sinclair QL single-handedly revolutionise computing? Aren't we all using stringy floppies today, as we whizz on our C5s to the Ministry of Space?
In your heart, you know it to be true.
I wish Gnome 3 would look and feel like OS X.
Ah, so you're the one person who's responsible for messing up my GNOME! Me and my, um 'attorneys', Fingers and GBH, would like a word wit' ye, in this back alley...
In all honesty, Windows 95's interface was terrible. It managed to be a step back from Windows 3 in many respects.
Interesting. I have a contrary opinion: to me, Windows 95 was the high-water mark of Microsoft's interface design and got some things right which everyone else - 2000s-era Microsoft included - have been strugging to even understand since.
Granted, the cascading Start Menu was horrible. But that can be fixed. The underlying "a shortcut on the menu is just a desktop shortcut inside a Menu folder" architecture was a stroke of utter genius, one GNOME completely failed to get. They had to create two incompatible kinds of launchers, and make it near-impossible to edit menus, or to drag one to the other. Why? The Win 95 way was so perfect.
The taskbar, too, is something that was brilliant compared to the Dock or anything else: an area that could show you at a glance where all your currently running stuff is. Yes, it's simplistic, and needs to be expanded - but the basic idea of dividing the screen into separate permanently-there areas, one which gives you an overview, one which gives you a closeup, was awesome. The big win of the Start Button is that (unless you really mess with things) it's always there in a known location. Same principle as Apple's menu (possibly they couldn't just do that because of look-and-feel patents? they were still a big deal in the mid-90s).
What I'd like is an interface which lets me extend this principle, to let me create user-defined fixed 'trays' in various parts of my desktop where I can guarantee that windows can't spill out of. For a while I thought Gnome's panels were going to be this, and I loved having one at the top and one at the bottom, one for menu and one for taskbar, but knowing that under the hood they were just identical instances of Panel.
I think the ultimate desktop still will be document-oriented - something like a Zoomable User Interface - rather than application-oriented, but we seem to have abandoned the quest for this and keep iterating on tiny visual variations of a half-finished underlying architecture, but now with the added pain that the user can't change the visual look and feel anymore. This seems like going in precisely the wrong direction. I'm at a loss to understand why this is. If we'd invested half the effort that's gone into force-feeding rigid visual look-and-feels onto an unwilling userbase, instead into creating an underlying architecture that seriously splits the look and feel from the underlying data and lets the userbase create and remix their own 'look' while the application developers can focus on the data processing - wouldn't we be a lot further ahead?
tldr: I don't want application designers telling me how to organise my desktop. I want them to give me the tools that let me organise my desktop however I want. But they're not. Why?
What I want to know is where you learn to build fusion reactors in humanities class.
It's in the music track; generally Jazz Fusion.
Critical Theory deals more with fission.
this tired, boring, uninformed and frankly idiotic meme
I assume you're posting this from your Mr. Fusion powered home and are preparing to take the generating world by storm. Good job old chap!
In the meantime, fusion continues not to happen.
He's referring to Helium 3 which is thought to be abundant on the moon and very rare here. Great for fusion power.
Yes, and the Cavorite deposits will also be very useful once we've developed a practical antigravity drive, which will be done about three decades before fusion achieves breakeven.
When I look up and see the Moon, I see a large amount of energy that soon could be within Humanities reach.
You mean if we deorbit it? Yeeees... that would certainly impart a large amount of energy very quickly. Might be a bit difficult to convert into anything except thermal and acoustic, but that's acceptable if we aim it at an uninhabited continent. Certainly worth investigating!
Jellyman to the rescue!!
He has the proportionate spinal strength and mobility of a jellyfish on land!
Don't worry, there's still a thriving uranium mining industry in Bartertown.
Sure, but if you inhale or eat any dust, you have a distance of 0. Extra special bonus if it's iodine or cesium or strontium, it gets incorporated into your body tissues or bones. Mmm crispy fried thyroid with a side of leukemia.
If that sells at good news, the spinmeisters are getting a bonus this year.
It's not a spinmeister, it's a Putzmeister!
They were the successful contractor, narrowly beating out industry competitors Schmucklord, Nimrodski and King Derp.
Most people in the world don't use computers. You can go now.
They don't? So who is it who's pasting captions on all those cats?
Or what?
Google? Amazon? Or a supercomputer somewhere in Langley gone quietly rogue?
A picture (GUI) is worth a thousand words.
On a 64-bit system, that's 4Kbytes. That's some compression algorithm you're using!
All interfaces can be done by passing streams of data with minimal predefined formatting
I think your analysis of the problem agrees with mine. The brittleness of OO/component programming with strictly typed interfaces vs the freedom of Unix piping.
Text, though, doesn't seem to quite cut it for exchanging structured data. Could there be a sweet spot in between?
I've been toying with ideas for universal lightweight 'structured data' languages. What if we had something like a shell which exchanged something like JSON? (Not really JSON because it's not fully universal - you can't, eg, express dictionaries containing dictionaries as keys - but something like that). Could we invent a whole new approach to 'pipeable untyped OO'?
This is an idea which is germinating in my mind for a new structured data format - table expressions. Very much draft, but I'm wondering if you would have useful comments?
I don't think that's true. Once you have seen a command-line program, you have seen all of them (ok, 95% of them).
On the other hand, every GUI-based program is different. You can't use the knowledge you gained on Visual Studio to work with Eclipse.
Interesting you should say that, because precisely the opposite was true in the 1980s on the IBM PC and MS-DOS platform. We had a whole marketplace of application software - WordStar, WordPerfect Lotus 1-2-3, Microsoft Word for DOS, dBase II - all of which had completely different command keys. When GUIs came along, the first thing they did was standardise basic functions like menus, navigation, and system utilities like fonts and printing.
If you weren't there, you can't imagine how unutterably hideous it was for every word processor to have to install its own printer driver. Or the Lovecraftian gibberish that was WordPerfect's function key template overlays. It used all ten F-keys, plus Ctrl, Alt and Shift. Mortal mind could not remember them all. If you pressed 'F1' it was not help. If you pressed 'Escape', it repeated the next action.
But now - at least until the last few years, before Microsoft's 'Ribbon' and Apple's i-devices - you knew if it's a GUI, it'll have menus, the left one will be 'File' and the right one 'Help', you can get context menus with right-click...
Now Apple and Microsoft (and GNOME 3) are doing their best to throw away 30 years of standardisation, and that's going to be like the 80s babel all over again, for you youngsters who missed it. Have fun!
In what way is a command line more flexible.
In short? A command line in the Unix sense is more flexible than a GUI in the Windows sense because in the Windows paradigm, there is no general graphical equivalent of a text editor. The closest equivalent is a graphical form builder as in Visual Studio, but you can't create, for example, a Powershell or VBScript file simply by dragging graphical components around. There's no inherent GUI reason why this should be the case and it would be super-neat if you could. But at the moment, you can't.
But even if you could create fully visual 'scripts' , a second way in which the command line is superior is that it is a 7-bit clean ASCII serial transport, which means that you can send a script through email, back it up securely, and transport it to other systems. GUI components are extremely tied to very specific OS and machine versions and do not transport or save well.
I believe this is a bad side-effect of the object-oriented programing philosophy that grew up alongside GUIs, which made opaqueness of implementation a religious tenet without realising that opaqueness prevents portability. OOP's encapsulation and data hiding rules almost deliberately reject portability, which is ironic because that's the opposite of OOP's proclaimed intentions.
If a standardised 7-bit clean text serialisation were created for every visual object on a Windows-like system - preferably one which was also cleanly human-editable as text - then we'd have something. But I think you'd have to deliberately break some deeply treasured OOP thinking to get there.
GUIs are appropriate to non-expert systems where functionality must be patently clear.
No, restricted interfaces are appropriate to non-expert systems. There's no a priori reason why a GUI must be a restricted interface, or a CLI should be a widely open one. This is the sort of muddled thinking which frustrates me.
In the days before GUIs, we implemented restricted interfaces either using 'menu' systems, or special-purpose command languages with a 'help' command which listed the available commands. Both are very simple to use. In fact, most GUIs can be seen as just graphical menus - and there's really no reason why an obscure icon should be more immediately understandable than a line of text describing the function. Often the reverse is true - this is why I like tooltips (explanatory text) and dislike Microsoft's 'ribbon' - opaque icons with no text.
But GUIs for advanced applications like 3D editors are very complicated and are not for beginners. We could make GUIs for the whole system which are just as powerful as CLIs (for example, you could build a 'command graph' rather than a 'command line' out of icons rather than names of tools).
It's just that we haven't. For historical reasons, not logical ones. The result is a hybrid system which is not entirely logical.
It's a two-dimensional grid: restricted choice menus vs open modifyable generative system, and CLI vs GUI. We shouldn't conflate the two axes.
This.
One thing our current GUIs lack is decent visual 'structured collection' conventions. It seems like it wouldn't necessarily be hard - a box for a collection, a line and arrow for a sequence - and then you could represent something like XML or any other structured-text format, including text-based programming languages, as a composite graphical construct. Then, if you could switch any subnode between text or graphical representations, and zoom in and out... wouldn't that be something?
Way back when Visual Basic first came out I was excited because I thought Microsoft was sensing this, and could give us access to the whole system in graphical form. But somehow it turned out not to be like that. Walls upon walls. VB vs C++, no way of graphically creating components themselves, lots of stuff with no visual representation, and rapidly evolving visual design languages in each new product line which kept destroying any hope for a universal visual language to emerge.
Squeak Smalltalk seems to be trying something similar. But it doesn't play well outside its own VM.
It's a holdover from a time when we thought words were a good way to express function.
(video clip of any scene from 'TNG:Darmok')
(roadsign with an exclamation point)
(picture of a flying pig)
I think you have TTV syndrome.
Teletype vampire? ... oh.
Talking television?
Talk to the Vole?
Tinkertoy vendor?
You wouldn't use a CLI to draw a network diagram.
No, but it would be really nice if the diagram editor loaded and saved as a series of CLI instructions, so that you could back up your network configuration, and then, eg, email it to a hosting company and have them run it through a script that automatically creates a bunch of virtual machines that replicates that network.
That's the level of CLI/GUI integration we need.
If you like to go out to the woods, cut down a tree, rip it into boards, plain and sand them, then build a chair, sand and finish it... that's great. But I just want to read a book... and buying a $10 chair at walmart will work fine.
The problem is that with today's architectures, the difference is more between assembling a chair from bare pine logs with an adze which you ground yourself, vs having a magic nuclear-powered nanotech chair pop into existence in your house when you think the colour blue, but which comes in only one size and colour, is bolted to the floor, randomly reconfigures itself every year, and if you ever try to look inside without a billion dollars of lab equipment, you get radiation burns and the nearest closet turns into a rabid badger.
It would be nice to have something somewhere in between. Even nicer would be to be able to buy a set of tools and lumber, or a prebuilt pine-wood chair with full assembly diagrams, and be able to repair it as you like.
If a human is required, it's editing.
That's your opinion. I think the point the original poster is making (certainly the point I'd make) is that our interfaces should be agnostic as to whether a human or a decision-making algorithm is driving them.
Because otherwise, how are we going to take control of our workflow and delegate the automatable parts of it to automation, if the interfaces we use stubbornly insist that 'no, a human must be in the loop to do that!'
This attitude, which sadly is rife among GUI designers, is keeping us stuck in the dark ages. It fundamentally shouldn't matter if a human or a program is doin any job on your desktop. End of story. It's not the interface's job to decide. If a script can take a look at a JPEG, apply a beauty algorithm and decide to fudge the colour contrast and recrop - and if a human can look at that afterwards and decide that it's good and keep it - well, then that's editing, isn't it? But it's done by a partnership of human and machine, as it should be.
Don't force us to decide between human and machine for every job, and especially, as an application designer, don't impose your conception of what tasks should be done by which. As a user, closer to the coalface, I might well have a better idea. If your software gets in the way of my automation, it's wrong.
GUI = makes it easy to do one off tasks, because the interface can be made intuitive.
CLI = makes it easy to do repetitive tasks, because they can be easily scripted.
That task split between GUI and CLI is exactly what I think went wrong when GUIs were first designed.
What we should have done was created a GUI which has exact formal one-for-one-correspondence with the underlying CLI, so that for any given task, you can use the interface of your choice that works for you - or create new graphical interfaces for the special custom jobs you end up doing multiple times.
And it wouldn't have been that hard to do. GUIs involve message passing, but we chose not to expose those messages as scriptable 'commands' at the same level as a CLI. We hid them and required C++ and other system/application languages to send those messages in full, then exposed a tiny fraction of them to various "scripting languages". But you can't write all applications in scripting languages, so it's a lossy conversion filter.
The result is, we've got at least three levels to our systems: a reasonably transparent 1960s-batch-system derived command/process/file based layer, an opaque 1980s Smalltalk-derived object/component layer, and finally combined applications/GUI/preference files launched by the 1960s layer which orchestrate the 1980s layer to do stuff. We can't use the 1960s layer (CLI) to do everything the 1980s layer (GUI plus services/components/DLLs) can do, because the 1960s layer has fundamental connection concepts like piping and "everything is a file which is an I/O stream" which simply don't exist in the 1980s "everything is an object" layer. It's impedance mismatch at the OS level.
The big problem with an impedance mismatch is that you can't solve it by adding more lossy-conversion layers. It can only be really "solved" by creating a new abstraction which has the features of both, but that seems impossible now that we have a huge weight of legacy code. I'd been hoping that Linux in the 2000s would give us some hope of breaking away from the Windows cruft and coming up with a simple unified desktop framework. But GNOME and KDE seem to have just fragmented the situation even more.
Wish I could see a plausible way out of this mess.