Live data from Hacker News

Loss32: Let's Build a Win32/Linux

loss32.org

361–370 of 493 posts

Re: Loss32: Let's Build a Win32/Linux

#361

Earlier quoted context omitted.

But to link against an old glibc version, you need to compile on an old distro, on a VM. And you'll have a rough time if some part of the build depends on a tool too new for your VM. It would be infinitely simpler if one could simply 'cross-compile' down to older symbol versions, but the tooling does not make this easy at all.

Huh? Bullshit. You could totally compile and link in a container.

Ok, so you agree with him except where he says “in a VM” because you say you can also do it “in a container”.

Of course, you both leave out that you could do it “on real hardware”.

But none of this matters. The real point is that you have to compile on an old distro. If he left out “in a VM”, you would have had nothing to correct.

Re: Loss32: Let's Build a Win32/Linux

#362

Thing is, I want the opposite. I want the NT/2k/w7 kernel and XFCE on top. NT kernel is infinitely better designed and has much better support on latest intel/amd hardware than Linux. And XFCE is much better than modern windows ui.

> has much better support on latest intel/amd hardware

In what way?

Re: Loss32: Let's Build a Win32/Linux

#363

I like the idea of it, but Linux hardware support is still crap, and will get worse as ARM becomes more entrenched. What boggles my mind is why Google hasn't gotten more serious about making Android a desktop OS. Pay the money needed to get good hardware support, control the OS, and now you're a Microsoft/Apple competitor for devices. Yes there is the Chromebook, but ChromeOS is not a real desktop OS, it's a toy. Goo…

> Linux hardware support is still crap What are you talking about? The majority of hardware is supported by only Linux at this point.

[deleted]

Re: Loss32: Let's Build a Win32/Linux

#364

Earlier quoted context omitted.

Huh? Bullshit. You could totally compile and link in a container.

Ok, so you agree with him except where he says “in a VM” because you say you can also do it “in a container”. Of course, you both leave out that you could do it “on real hardware”. But none of this matters. The real point is that you have to compile on an old distro. If he left out “in a VM”, you would have had nothing to correct.

I'm not disagreeing that glibc symbol versioning could be better. I raised it because this is probably one of the few valid use cases for containers where they would have a large advantage over a heavyweight VM.

But it's like complaining that you might need a VM or container to compile your software for Win16 or Win32s. Nobody is using those anymore. Nor really old Linux distributions. And if they do, they're not really going to complain about having to use a VM or container.

As C/C++ programmer, the thing I notice is ... the people who complain about this most loudly are the web dev crowd who don't speak C/C++, when some ancient game doesn't work on their obscure Arch/Gentoo/Ubuntu distribution and they don't know how to fix it. Boo hoo.

But they'll happily take a paycheck for writing a bunch of shit Go/Ruby/PHP code that runs on Linux 24/7 without downtime - not because of the quality of their code, but due to the reliability of the platform at _that_ particular task. Go figure.

Re: Loss32: Let's Build a Win32/Linux

#365

I like the idea of it, but Linux hardware support is still crap, and will get worse as ARM becomes more entrenched. What boggles my mind is why Google hasn't gotten more serious about making Android a desktop OS. Pay the money needed to get good hardware support, control the OS, and now you're a Microsoft/Apple competitor for devices. Yes there is the Chromebook, but ChromeOS is not a real desktop OS, it's a toy. Goo…

> Linux hardware support is still crap What are you talking about? The majority of hardware is supported by only Linux at this point.

There is plenty of hardware that is either unsupported or poorly supported. I have personally run into a dozen different devices and several architectures that were unsupported. And I'm just one person buying normal stuff in stores.

Re: Loss32: Let's Build a Win32/Linux

#367

Earlier quoted context omitted.

> and why all modern native UI frameworks have a similar model these days. Personally I much rather the approach taken by solidjs / svelte. React’s approach is very inefficient - the entire view tree is rerendered when any change happens. Then they need to diff the new UI state with the old state and do reconciliation. This works well enough for tiny examples, but it’s clunky at scale. And the code to do diffing and…

>React’s approach is very inefficient - the entire view tree is rerendered when any change happens. That's not true. React only re-renders down from where the update happens. And it skips over stuff that is provably unchanged -- which, fair, involves manual memoization hints. Although with React Compiler it's actually pretty good at automatically adding those so in practice it mostly re-renders along the actually cha…

> That's not true. React only re-renders down from where the update happens. And it skips over stuff that is provably unchanged -- which, fair, involves manual memoization hints.

React only skips over stuff that's provably unchanged. But in many - most? web apps, it rerenders a lot. Yeah, you can add memoization hints. But how many people actually do that? I've worked on several react projects, and I don't think I've ever seen anyone manually add memoization hints.

To be honest it seems a bit like Electron. People who really know what they're doing can get decent performance. But the average person working with react doesn't understand how react works very well at all. And the average react website ends up feeling slow.

> Most of complexity of React is elsewhere.

Where is the rest of the complexity of react? The uncompressed JS bundle is huge. What does all that code even do?

> I actually count [solidjs / svelte] as "React-like" because it's still declarative componentized top-down model unlike say VB6.

Yeah, in the sense that Solidjs and svelte iterate on react's approach to application development. They're kinda React 2.0. Its fair to say they borrow a lot of ideas from react. And they wouldn't exist without react. But there's also a lot of differences. SolidJS and Svelte implement react's developer ergonomics, while having better performance and a web app download size that is many times smaller. Automatic fine grained reactivity means no virtual dom, no vdom diffing and no manual memoization or anything like that.

They also have a trick that react is missing: Your component can just have variables again. SolidJS looks like react, but your component is only executed once per instance in the page. Updates don't throw anything away. As a result, you don't need special react state / hooks / context / redux / whatever. You can mostly just use actual variables. Its lovely. (Though you will need a solidjs store if you want your page to react to variables being updated).

Re: Loss32: Let's Build a Win32/Linux

#368

Earlier quoted context omitted.

At least glibc uses versioned symbols. Hundreds of other widely-used open source libraries don't.

Yeah and nothing ever lets you pick which versions to link to. You're going to get the latest ones and you better enjoy that. I found it out the hard way recently when I just wanted to do a perfectly normal thing of distributing precompiled binaries for my project. Ended up using whatever "Amazon Linux" is because it uses an old enough glibc but has a new enough gcc.

You can choose the version. There was apgcc from the (now dead) Autopackage project which did just that: https://github.com/DeaDBeeF-Player/apbuild

Re: Loss32: Let's Build a Win32/Linux

#369

Earlier quoted context omitted.

Only because people aren't putting in the effort to build their binaries properly. You need to link against the oldest glibc version that has all the symbols you need, and then your binary will actually work everywhere(*). * Except for non-glibc distributions of course.

But to link against an old glibc version, you need to compile on an old distro, on a VM. And you'll have a rough time if some part of the build depends on a tool too new for your VM. It would be infinitely simpler if one could simply 'cross-compile' down to older symbol versions, but the tooling does not make this easy at all.

It's actually doable without an old glibc as it was done by the Autopackage project: https://github.com/DeaDBeeF-Player/apbuild

That never took off though, containers are easier. Wirh distrobox and other tools this is quite easy, too.

Re: Loss32: Let's Build a Win32/Linux

#370

Earlier quoted context omitted.

> tree-like file systems, multiple users, access privileges, Why should everything pretend to be a 1970s minicomputer shared by multiple users connected via teletypes? If there's one good idea in Unix-like systems that should be preserved, IMHO it's independent processes, possibly written in different languages, communicating with each other through file handles. These processes should be isolated from each other, an…

Indeed. AmigaOS was the pinnacle of personal computing OS design. Everything since has been a regression. Fite me.

What about BeOS ?
Post reply on HN