Hacker News Reader

Comment by mhd | Hacker News Reader

It also seems to combine the worst of both platforms: Apps.

Is there any OSDEV work that goes towards a more integrated, component-based architecture? As sad as it seems, Unix tools & pipes seems to be the most successful and enduring attempt in that direction. Systems doing that on a language basis seem mostly dead (Lisps, Smalltalks, Oberons), component architecture isn't doing much (OpenDoc as the prime example, CORBA/COM to a minor degree).

I don't think we'll be breaking much new ground when it just comes down to more efficient runtimes, packaging and ways to launch the same old ultra-tightly focused applications.

View on HN

Component architecture is everywhere on the desktops, just not on those using UNIX text terminals.

COM has been the underlying driving technology of Windows since Vista, where the Windows team took the Longhorn .NET ideas and redid them with COM, since then we got COM improved as WinRT/UWP. Which despite the common mix with the store (blame marketing teams), is what to this day most Windows 10 APIs make use of, and now even React Native for Windows is built on top of.

On Apple side, we have XPC being increasingly used, while Android uses a mix Binder and Activities, also the same IPC mechanism powering Treble based drivers.

XFCE, GNOME and KDE make heavy use of DBUS.

Then I laugh of joy with hype around gRPC, as everyone is just rediscovering CORBA.

Lisps, Smalltalks, Oberons ideas can be replicated on top of those component stacks, which is what Powershell actually does to certain extent on Windows.

The tools are there, learn to use them Luke.

> XFCE, GNOME and KDE make heavy use of DBUS.

Only for IPC. There is no IPC within a typical glib app.

GObject keeps working flawlessly, but it is too arcane to newcomers (which are already few because of C itself becoming an arcane art these days)

Systemd uses DBUS for comunication between its processes & the Cockpit admin web UI uses DBUS for talking to all the things it can manage.

As much as I like to bash C, even Microsoft was forced to reconsider their position and latest MSVC now supports C11 and C17, and UNIX kernels won't ever use anything else.

So anyone serious about OS development should know it, regardless of their opinion towards the language.

As for GObject, there are bindings for almost any relevant language.

You have my solidarity, but I do not see C having a resurgence.

Can share horror stories of expensive hires with MSc/PhD degrees, and years of experience having a fright of their lifetime when they see real world C.

So are you planning to rewrite all those UNIX clones in something else?

Azure Sphere, Microsoft's paragon of IoT security, only allows for C.

Those expensive MSc/PhD should just complain to their universities for not providing a proper systems programming classes.

I clearly need people who can do above helloworld level in C.

For many places, there are clearly no alternative to C.

The humongous open codebase of high quality C code, exceeding every other language, is also not going anywhere.

The situation is, shortly speaking, "no alternative to doing it in C, but we cannot do it in C because of some purely non-technical constraint." And the situation is very common I feel.

Chipmakers with billions of cash free to throw on RnD can't make any passable Linux kernel work. Google Chrome team must be employing best C++ hackers on the market, and yet.... and the story goes on like this.

The relative overabundance of webdev/java people hides the the fact that we are not only not gaining developers in conventional programming, but losing them fast to age, career change, or them returning back to home countries in case of labour migrants.

Those Java people also need to be at home with the low level concepts, if they are to do any usable work from what is coming from Panama.

Likewise those Webdevs might just brush up their skills for WebAssembly.

At the end of the day it doesn't matter if one is using D, Rust, Swift, Java, C#, Rust, C++, Zig, FreePascal, CUDA, Open... instead of C.

The system programming concepts are the same, and it all boils down to education.

As for lousy candidates, I get them in any language.

Can't say them not knowing them at all, or them being outright lousy.

When it come to CS fundamentals, algorithmics, most were better than me, who never studied CS academically. This was the reason we ever took interest in them.

It's just you cannot compensate for training, and experience with overall feel of skill. You can hire an ACM olympian, and the guy will still loose it unless he did C professionally for 3-4 years.

In my engineering degree doing stuff like B-Trees with its own i-node management module in C, validate against unit tests written by the professor, were requirements just to qualify for the data structures exam.

Someone lousy in low level coding won't go through such a curriculum,

https://www.di.fct.unl.pt/en/education/integrated-master-com...

Again, a matter of teaching quality.

Any other "real world" software can be ugly and can be beautifully written in any language, including C (except ones where being cryptic is by design).

Basic C can be picked up in very short time. there is nothing to be frightened about. When I first laid my hands on C I wrote working software (keyboard driver for DOS) in a first day as a learning exercise. Not sure what other than incompetence as a programmers is causing your expensive PhDs "fright of their lifetime".

> Not sure what other than incompetence as a programmers is causing your expensive PhDs "fright of their lifetime".

Memory management, handwritten loops, pointers everywhere, absence of ready made data structures, error handling (or its absence,) epopeia with C strings, sanitizing inputs, and nausea from the slightest smell of SIMD, or basic binary hackery to begin with.

Those are needed for the tasks C was made to handle: complete control over everything being a primary one. If you do not need those tasks you do not need C. And if you do then get used to it.

Odd how well rust seems to manage to avoid them.

C was amazing when it was introduced, but is as archaic as COBOL today. We are stuck with it because of legacy.

>"C was amazing when it was introduced"

It was not amazing. It was decent particular tool for particular job. That was all about it. Same thing about Rust. There are no silver bullets laying around.

Whether you want to say it was amazing or not, it’s a legacy tool now.

What do the cool kids use to write realtime or realtime-ish software with these days? What gets used for firmware? What gets used to write kernels? What gets used when you have to interact with hardware that uses memory mapped registers?

It might be C++ instead of C for some of the above, but that doesn't make C "a legacy tool".

I’m not saying it isn’t used.

I’m saying it’s a legacy tool from the early 70’s that is absolutely terrible compared to what we could have.

Cool kids use it because there is no alternative.

It is not

Two words: Buffer overrun

Amazing only to those that never looked outside Bell Labs.

Amazing was what Burroughs was doing in 1961, 10 years before C came to be, IBM RISC research in PL/S and PL.8, VAX/VMS stuff in BLISS, Solo OS in Concurrent Pascal, Xerox XDE in Mesa, ....

Those were amazing in the 60's and mid-70's.

> GObject keeps working flawlessly, but it is too arcane to newcomers (which are already few because of C itself becoming an arcane art these days)

I keep looking for a good excuse to learn Vala. Maybe this is it.

You may also consider doing it in Rust.

It's possible to implement GObject subclasses in Rust which little additional overhead as compared to doing it in C, but you get the syntactical niceties of for each loops, traits, and other features of Rust.

librsvg makes good use of these bindings, and is undergoing a rewrite in Rust. Gstreamer bindings are also becoming more complete, and example implementations of many of the standard plugins have been rewritten. The official implementation is still in C though.

Vala is a neat concept though and a pretty clean language.

https://people.gnome.org/~federico/blog/librsvg-gobject-in-r...

https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs

> You may also consider doing it in Rust.

The Vala compiler complains about my code. The Rust one tears it to shreds.

I understand Rust's constructive criticism is coming from a good place, but it's still very harsh ;-)

> librsvg makes good use of these bindings, and is undergoing a rewrite in Rust.

And is losing support for older CPU architectures as a result.

I really hope we don't see this more before the rust compiler is improved to support older architectures, as otherwise it may become prohibitively difficult to revive older systems...

> There is no IPC within a typical glib app.

Except for anything to do with the UI, although admittedly, the details of this is usually hidden within the relevant libraries.

Why would any typical app have IPC within it?

I mentioned because some of that "componentised" style apps do indeed what amounts to intra-interprocess-communication for god knows what reason. Android for example

Are you talking about Component Object Model, COM? If so, that predates Vista by many Windows releases.

Of course it predates Vista.

"Windows team took the Longhorn .NET ideas and redid them with COM"

Nowhere did I wrote that Vista introduced COM.

gRPC is not a CORBA equivalent though. Was CORBA ever intended for APIs operating over IP networks?

Yes, naturally. How do you think we were using it in the 2000?

For those that don´t know it, IIOP.

http://panuganty.tripod.com/articles/iiop.htm

Not to mention EJBs

I'm not sure where you're getting "COM has been the underlying driving technology of Windows since Vista".

COM and OLE, which is based on COM, have been a core part of the Windows shell since at least Windows 95/NT 4.0/IE 4.

You can see this in the registry where shell extensions are simply registered OLE Components, using OLE Activation to to register themselves as toolbars, folder views, context menus and additional commands in context menus.

If you are referring to drivers or core OS concepts at a lower level, you may be right, but DirectX and class drivers were already using COM in places before Vista.

COM is a standard vtable implementing a single core interface, called IUnknown which provides a method of reference counting as well as a way to look up implementaions of specific other interfaces from a given pointer. These interfaces dervive from that base, so they can always be cast as IUnknown.

The rest builds on this base.

source: Inside OLE and Inside Windows 95

https://books.google.com/books/about/Inside_OLE.html?id=adpw...

https://www.bookdepository.com/Inside-Windows-95-Deluxe-Edit...

Edit: saw the reply below, the specific Longhorn components only expanded the scope of what is extensible to include searchable/virtual/indexed filesystem extensions and few other places, based on the innovative concepts in Longhorn. My reading of your comment originally was that Vista was a departure from what came before, though it appears that it may have been intended to say it was more of a return to the simpler COM.

Maybe I should have phrased it in another way.

For you to get where I am coming from, for me Longhorn only failed due to the usual set of politics between DevDiv and WinDev that those of us on Windows know so well throughout the years.

Had they actually worked together and Longhorn, with .NET based stack would have happened, just like it did with Android and ChromeOS. When technical limitations exist, they can be sorted out when everyone rows into the same direction.

So after its failure, and reboot as Vista, the Windows team took many of the Longhorn ideas and redid them as COM libraries.

This decision started a trend (hence my started with Vista), where all major new APIs that were added to Windows since then, were COM based instead of classical Win32.

You can see this by following the C++ Hilo tutorial later released for Windows 7.

When Windows 8 came to be, they decided to double down on this direction and came up with WinRT, which if you read the Ext-VOS paper, looks quite similar. Ext-VOS being what was being designed as successor to VB/C++/J++ as COM evolution, before all the events that made .NET happen.

So you got the Windows team creating WinRT, they also had their own shot at what .NET should be, hence why it uses AOT based compilation with a compiler that only supports the MSIL sets that they cared about.

As we all know by now, due to several reasons this did not turn out as expected, still UWP (as COM evolution is now know) is still the way to go to all major APIs, even in the context of Project Reunion.

So we changed from Win32 + some relevant projects using COM, to Win32 mostly frozen in Windows XP API level + everything else is COM/UWP based.

This was my point about Vista being the turning point where this took place.

I might be wrong, but this is how I see the evolution of those events.

> The tools are there, learn to use them Luke.

That's the, excuse my Huttese, friggin' point. We had versions of those tools for ages. And once we even had high hopes of using them outside of a dev's context -- the aforementioned OpenDoc for example, but even early Linux DE's seemed to have some intentions of going that route. I remember using the GNOME CORBA implementation because I needed something that would compile with a proprietary workstation C compiler (no C++).

And it's not even hard to see why we're not doing it -- money and bikeshedding. We're selling apps. Heck, we've gone a step beyond that and don't even do that anymore, we're selling services now. There are two environments where you could go beyond that -- made for hire enterprise software and open source (I've given up on academia, especially after the bachelor-splosion). But that's where the second part comes in play -- most enterprises have given up on trying to come up with some overarching architecture, things are moving too fast and there are too many managers.

Whereas there are too few in open source. Never mind that a lot of open source these days is just commercial turds, github profiling and heavily influenced by what you're doing in your day job.

Conway's Law is really screwing us over.

Yes, we have all the tools to e.g. create a desktop where you could have your favorite editor widget in all contexts, where interoperation isn't just dropping stuff into UTF-8 files, to be massaged by scripts and other applications.

I doubt that it will get better. There's a whole generation starting to fill the FAANG bullpens that never saw anything beyond the cordoned appscapes of their indistinguishable mobile devices. Maybe someone will notice that "hey, I'm using this insanely clever federated way of connecting my microservices with <rpc-du-jour>, what if...". Probably will end up on something like the suckless/unixpr*n pages and go a few steps too far, banging ASCII rocks together to summon the holy gopher.

What if unix style pipes included a MIME type. Thus you might have some type safety, or ability to understand multiple types of input.

Example: if one tool outputs JSON, another tool, like grep, would recognize that is a subtype TEXT, and be able to process it.

Example: a more sophisticated hypothetical grep tool, would recognize that it might grep JSON differently than it greps TEXT.

Example: Tool 1 exporting JPEG might be incompatible with Tool 2 that only accepts JSON. A nice shell error message could result.

[Nushell](https://www.nushell.sh/) is doing something along those lines. They have plenty of work to go before it's perfect, but it's already surprisingly good.

We initially experimented with almost exactly what was described here, but it lacked one thing and that was third party expandablility. Sadly, I see no way for common and modern apps in their current form to be integrated into anything other than the traditional application format. If this changes, I hope to be the first to jump on board and get the ball rolling.

Dbus seems to be doing really well in recent decade. Sound, networking, system management already use it on Linux. It's likely only going to get more common. With the well defined interfaces seems to be a reasonable solution for system and user components.

What does the "unix"ness of stuff have to do with the lack of popularity of linux as a market? Blaming a technical problem for what is actually social does nothing positive for anyone. Certainly, "linux" itself as a free platform is not necessary for liberation, let alone the litany of other brands you mentioned. Linux is unpopular for many, many other reasons than avoiding technical issues.

If "unix" is considered a success, I'm giving up on coding. What's the point? People will just gravitate towards brand loyalty regardless of the technical underpinnings.

When will it implement plan9's bind?

There is plan9.

Don't forget HarveyOS!

Which is a plan 9 fork.

Reply on news.ycombinator.com