10 ms·

I can't help but think about what happened with graphics APIs - the older ones (DX9, OpenGL) held your hand more, and the new ones are super bare metal and not

I can't help but think about what happened with graphics APIs - the older ones (DX9, OpenGL) held your hand more, and the new ones are super bare metal and not written for the faint of heart. I think most would agree this is better though; for an application developer you can simply use a much higher level library built on top, and for the library/engine developer you have a lot more power and control. The old APIs were in an awkward middle ground of not being particularly easy to use, but also not being nearly low level enough. Nobody was happy. I think modern OS stacks are in a similar boat, at least Windows and macOS. True low level control is kind of a pain, but the OS libraries are not particularly pleasant or high level enough either. So largely things like Electron or Qt are acting as the defacto OS anyway to varying degrees of success but undeniable levels of resource waste. I wonder if modern languages and tooling and such are advanced enough that the OS should become more primitive and minimal. In a way it feels like we're moving there anyway with web tech becoming the defacto user space and toolkit. That's fine, but god if it wasnt all built on 50 layer of cruft our machines would be screaming fast. Smalltalk, if you get a chance to use it, really does act like its own OS in so many ways. It's great as a programmers OS really, although it doesn't really hit the right notes for average use. Still though, if someone had the urge to build it I could easily see a smalltalk based userland built on like a linux kernel (with no gnu user space) being a totally viable thing.

tehsauce 5y ago
very interesting take, thanks for sharing
pjmlp 5y ago
Nah, Android, macOS and Windows are doing just fine, it is the classical UNIX desktop that cannot get their act together. The existing issues aren't technical, rather political, like the WinRT crusade that ended up bombing and now we have plenty of GUI toolkits to chose from on Windows. Swift, Java, Kotlin and the .NET languages are more than high level enough.
- otabdeveloper4 5y ago
  > the classical UNIX desktop CDE? That hasn't existed for decades.
  - pjmlp 5y ago
    Who cares about CDE, the classical UNIX desktop, as in the way that BSDs and GNU/Linux keep pushing for the old days with their fragmented stacks. macOS, although a UNIX, follows the same ideolagy as NeXTSTEP, where UNIX compatibility was a means to bring software into the platform, and that was about it, GUI software was to be fully taken advantage of Objective-C Frameworks.
    - otabdeveloper4 5y ago
      My point is that "classical UNIX desktop" doesn't exist. (Hell, even UNIX itself doesn't exist anymore. Linux and FreeBSD is its own thing now.)
      - pjmlp 5y ago
        It sure does exist, a large majority of Linux and FreeBSD users pretend they are still living in the 80's with vt100 and an improved twm. As proven by https://news.ycombinator.com/item?id=28437173 https://news.ycombinator.com/item?id=28437173 making to the first page today.
        5e92cb50239222b 5y ago
        How do you find time for work? I see your comments shitting on everything that's not Windows pretty much everywhere.
        pjmlp 5y ago
        https://xkcd.com/303/ https://xkcd.com/303/ You missed my praises for Apple and Google platforms.
AussieWog93 5y ago
>I think modern OS stacks are in a similar boat, at least Windows and macOS. I come from a background as a EEE mainly writing embedded code before somehow stumbling into frontend code (in win32, Cocoa and Qt) at my old job. From my experience, OS-Level APIs definitely have more in common with Electron or Qt than they do "bare metal". To make the top left pixel red on a bare metal system or RTOS, you simply write `framebuffer[0] = 0x00ff0000`. For win32 or Cocoa, you need to create a window, alter its flags to ensure it's borderless, change its size and posistion to 1x1 and [0,0] (or [0, screen_height] on the Mac), strip away the drop shadow, respond to regular paint events and pray like hell that nothing else draws over the top of it. >True low level control is kind of a pain It depends on what you're trying to achieve. If you're trying to get something highly responsive that looks exactly like the UI spec, most libraries tend to make this job harder when the abstractions leak and you're forced to rely on bizarre hacks that make no sense and feel genuinely demoralising to implement. Dear ImGui, which exposes far more of the low-level internals than any other API, is an absolute joy to build GUIs in and significantly easier than something which "holds your hand" at every step.
- nyanpasu64 5y ago
  Dear ImGui does not support Arabic (right-to-left, glyph shaping) and will not support Arabic (https://github.com/ocornut/imgui/issues/1343 https://github.com/ocornut/imgui/issues/1343). I don't think it supports accessibility either. As much as I struggle with Qt's APIs (aging janky Widgets, half-baked QML on the desktop, the item models are an impenetrable byzantine enterprisey API that's simultaneously too open-ended, not flexible enough since it imposes its add/remove/move schema on your model, and too buggy), building a GUI from the ground up is not going to give you internationalization or accessibility, and Qt is.
  - AussieWog93 5y ago
    >Dear ImGui does not support Arabic (right-to-left, glyph shaping) and will not support Arabic (https://github.com/ocornut/imgui/issues/1343 https://github.com/ocornut/imgui/issues/1343). Vanilla ImGui doesn't, but I both wrapped my head around and then rewrote the text renderer in all of 2 days as a junior dev. This version could support arbitrarily many UTF-8 codepoints with kerning and all and had a negligible performance hit on the machines I tested on. I never upstreamed it (left the company before the product that was using it shipped, actually), but it wouldn't be too hard to reproduce. That's what I love about exposed, lower-level frameworks like Dear ImGui. We didn't aim for accessibility, but I'm sure that would have also been semi-trivial for a dedicated dev who understands what's required.
kumarvvr 5y ago
>True low level control is kind of a pain, but the OS libraries are not particularly pleasant or high level enough either Wait. In that case, library developers or OSS projects can fill the gap. What am I missing here? QT comes to mind. A high level library for GUI programming. Also, the modern .NET stack. I always thought the popularity of Electron is because GUI programming is insanely easy on it, and if you have apps that are heavily data dependent, you go with it because the alternatives (Native apps, WPF or Winform apps) do not provide any value addition.
- klodolph 5y ago
  Electron is popular because it makes cross-platform desktop apps easier, or because developers have existing JavaScript code that they want to share between a desktop app and a web app. I would say that if you just wanted to spit out a Windows application, and you already knew the technologies, WPF or Winforms would probably be better (despite the fact that WinUI is the new hot stuff).
bsdubernerd 5y ago
The OS is all about resource sharing and allow a minimum common level of interoperability. Smalltalk can provide a storage abstraction, but to interoperate with other things it needs to be able to save data in a way that can be loaded back into your Java program. OSes can provide you with the desired abstraction level. You could stop at the block layer, which many DBs can take advantage of, but that won't help your Java and Smalltalk program work together easily. A filesystem is a common abstraction which should provided by someone. Your example about the graphics stack is no different, the problem is that various components of the system are not "shared" in the same way all the time. The actual low-level abstraction of the GPU being provided to you by the kernel has more complexity today than what it had years ago in order to allow virtualization and compartmentalization of graphics memory. This wasn't needed some years ago, as it was assumed X11 was the only program to ever going to access the framebuffer, and would allow any single program using GL to trash the entire GPU. What has been simplified is the user-level facing code, so that you can more precisely control allocation of the resources. Akin to the page-level memory allocation support we always had. This was done to allow /some/ programs (3d engines) to push the hardware to the limits (I'm relatively sad the GL1.x is "deprecated" - I still consider it to be an excellent API for prototyping and what would be 90%+ of applications). Consider audio instead. OSS always provided pretty much all the hardware features, but allow no resource sharing. Every single evolution on that front has been an increase in complexity to allow for resource sharing. And it's interesting because the effort went in and out of the kernel a couple of times. Describing the evolution of OSS/ALSA in linux/freebsd would be too long, however we now have very fat daemons sitting in front of the HW just for resource sharing.
- account42 5y ago
  > Consider audio instead. OSS always provided pretty much all the hardware features, but allow no resource sharing. Every single evolution on that front has been an increase in complexity to allow for resource sharing. None of the API changes were required for resource sharing though so that complexity could (and should) have been contained to the implementation and those applications that actually need new features.
  - 5y ago
oshiar53-0 5y ago
You might find the Exokernel approach interesting. https://en.wikipedia.org/wiki/Exokernel https://en.wikipedia.org/wiki/Exokernel
paulddraper 5y ago
> So largely things like Electron or Qt are acting as the defacto OS anyway to varying degrees of success That's the natural (and arguable optimal) state of things: lower levels and higher levels. High-level developers use high-level things, low-level developers use low-level things. Every once in awhile someone gets the bright idea to combine all the layers into one, but finds out that in the real world that just isn't practical. But we get developers pulling apart and adding layers over and over, driven by a love for "simplicity." Moving forward, or in circles? Hard to say, but probably forward.

tehsauce 5y ago

very interesting take, thanks for sharing

pjmlp 5y ago

Nah, Android, macOS and Windows are doing just fine, it is the classical UNIX desktop that cannot get their act together. The existing issues aren't technical, rather political, like the WinRT crusade that ended up bombing and now we have plenty of GUI toolkits to chose from on Windows. Swift, Java, Kotlin and the .NET languages are more than high level enough.

otabdeveloper4 5y ago
> the classical UNIX desktop CDE? That hasn't existed for decades.
- pjmlp 5y ago
  Who cares about CDE, the classical UNIX desktop, as in the way that BSDs and GNU/Linux keep pushing for the old days with their fragmented stacks. macOS, although a UNIX, follows the same ideolagy as NeXTSTEP, where UNIX compatibility was a means to bring software into the platform, and that was about it, GUI software was to be fully taken advantage of Objective-C Frameworks.
  - otabdeveloper4 5y ago
    My point is that "classical UNIX desktop" doesn't exist. (Hell, even UNIX itself doesn't exist anymore. Linux and FreeBSD is its own thing now.)
    - pjmlp 5y ago
      It sure does exist, a large majority of Linux and FreeBSD users pretend they are still living in the 80's with vt100 and an improved twm. As proven by https://news.ycombinator.com/item?id=28437173 https://news.ycombinator.com/item?id=28437173 making to the first page today.
      - 5e92cb50239222b 5y ago
        How do you find time for work? I see your comments shitting on everything that's not Windows pretty much everywhere.
        pjmlp 5y ago
        https://xkcd.com/303/ https://xkcd.com/303/ You missed my praises for Apple and Google platforms.

AussieWog93 5y ago

>I think modern OS stacks are in a similar boat, at least Windows and macOS. I come from a background as a EEE mainly writing embedded code before somehow stumbling into frontend code (in win32, Cocoa and Qt) at my old job. From my experience, OS-Level APIs definitely have more in common with Electron or Qt than they do "bare metal". To make the top left pixel red on a bare metal system or RTOS, you simply write `framebuffer[0] = 0x00ff0000`. For win32 or Cocoa, you need to create a window, alter its flags to ensure it's borderless, change its size and posistion to 1x1 and [0,0] (or [0, screen_height] on the Mac), strip away the drop shadow, respond to regular paint events and pray like hell that nothing else draws over the top of it. >True low level control is kind of a pain It depends on what you're trying to achieve. If you're trying to get something highly responsive that looks exactly like the UI spec, most libraries tend to make this job harder when the abstractions leak and you're forced to rely on bizarre hacks that make no sense and feel genuinely demoralising to implement. Dear ImGui, which exposes far more of the low-level internals than any other API, is an absolute joy to build GUIs in and significantly easier than something which "holds your hand" at every step.

nyanpasu64 5y ago
Dear ImGui does not support Arabic (right-to-left, glyph shaping) and will not support Arabic (https://github.com/ocornut/imgui/issues/1343 https://github.com/ocornut/imgui/issues/1343). I don't think it supports accessibility either. As much as I struggle with Qt's APIs (aging janky Widgets, half-baked QML on the desktop, the item models are an impenetrable byzantine enterprisey API that's simultaneously too open-ended, not flexible enough since it imposes its add/remove/move schema on your model, and too buggy), building a GUI from the ground up is not going to give you internationalization or accessibility, and Qt is.
- AussieWog93 5y ago
  >Dear ImGui does not support Arabic (right-to-left, glyph shaping) and will not support Arabic (https://github.com/ocornut/imgui/issues/1343 https://github.com/ocornut/imgui/issues/1343). Vanilla ImGui doesn't, but I both wrapped my head around and then rewrote the text renderer in all of 2 days as a junior dev. This version could support arbitrarily many UTF-8 codepoints with kerning and all and had a negligible performance hit on the machines I tested on. I never upstreamed it (left the company before the product that was using it shipped, actually), but it wouldn't be too hard to reproduce. That's what I love about exposed, lower-level frameworks like Dear ImGui. We didn't aim for accessibility, but I'm sure that would have also been semi-trivial for a dedicated dev who understands what's required.

kumarvvr 5y ago

>True low level control is kind of a pain, but the OS libraries are not particularly pleasant or high level enough either Wait. In that case, library developers or OSS projects can fill the gap. What am I missing here? QT comes to mind. A high level library for GUI programming. Also, the modern .NET stack. I always thought the popularity of Electron is because GUI programming is insanely easy on it, and if you have apps that are heavily data dependent, you go with it because the alternatives (Native apps, WPF or Winform apps) do not provide any value addition.

klodolph 5y ago
Electron is popular because it makes cross-platform desktop apps easier, or because developers have existing JavaScript code that they want to share between a desktop app and a web app. I would say that if you just wanted to spit out a Windows application, and you already knew the technologies, WPF or Winforms would probably be better (despite the fact that WinUI is the new hot stuff).

bsdubernerd 5y ago

The OS is all about resource sharing and allow a minimum common level of interoperability. Smalltalk can provide a storage abstraction, but to interoperate with other things it needs to be able to save data in a way that can be loaded back into your Java program. OSes can provide you with the desired abstraction level. You could stop at the block layer, which many DBs can take advantage of, but that won't help your Java and Smalltalk program work together easily. A filesystem is a common abstraction which should provided by someone. Your example about the graphics stack is no different, the problem is that various components of the system are not "shared" in the same way all the time. The actual low-level abstraction of the GPU being provided to you by the kernel has more complexity today than what it had years ago in order to allow virtualization and compartmentalization of graphics memory. This wasn't needed some years ago, as it was assumed X11 was the only program to ever going to access the framebuffer, and would allow any single program using GL to trash the entire GPU. What has been simplified is the user-level facing code, so that you can more precisely control allocation of the resources. Akin to the page-level memory allocation support we always had. This was done to allow /some/ programs (3d engines) to push the hardware to the limits (I'm relatively sad the GL1.x is "deprecated" - I still consider it to be an excellent API for prototyping and what would be 90%+ of applications). Consider audio instead. OSS always provided pretty much all the hardware features, but allow no resource sharing. Every single evolution on that front has been an increase in complexity to allow for resource sharing. And it's interesting because the effort went in and out of the kernel a couple of times. Describing the evolution of OSS/ALSA in linux/freebsd would be too long, however we now have very fat daemons sitting in front of the HW just for resource sharing.

account42 5y ago
> Consider audio instead. OSS always provided pretty much all the hardware features, but allow no resource sharing. Every single evolution on that front has been an increase in complexity to allow for resource sharing. None of the API changes were required for resource sharing though so that complexity could (and should) have been contained to the implementation and those applications that actually need new features.
- 5y ago

oshiar53-0 5y ago

You might find the Exokernel approach interesting. https://en.wikipedia.org/wiki/Exokernel https://en.wikipedia.org/wiki/Exokernel

paulddraper 5y ago

> So largely things like Electron or Qt are acting as the defacto OS anyway to varying degrees of success That's the natural (and arguable optimal) state of things: lower levels and higher levels. High-level developers use high-level things, low-level developers use low-level things. Every once in awhile someone gets the bright idea to combine all the layers into one, but finds out that in the real world that just isn't practical. But we get developers pulling apart and adding layers over and over, driven by a love for "simplicity." Moving forward, or in circles? Hard to say, but probably forward.