Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make Apps for Linux

makealinux.app

Post reply on HN
Print view View original

321–330 of 422 posts

Re: Make Apps for Linux

#321

Post by sph »

pjmlp wrote: post #319
anonyme-honteux wrote: post #297

Earlier quoted context omitted.

You are talking about Android and Chrome OS right? I agree, those are the top two Linux distributions, and everything else is behind by an absolutely huge margin

Yep. Just browse their documentation, that is the kind of development experience GNOME and KDE were expected to provide, 20 years ago, yet fail short due to Linux distributions fragmentation, the devs using other environments, or still stuck with plain window managers and xterms workflows.

If only GNOME and KDE were backed by one of the largest companies in the world, with tens of billions of dollars at its disposal.

Re: Make Apps for Linux

#322

Post by sph »

tasn wrote: post #13
zjp wrote: post #5

Maybe I'm just too ignorant to know the pattern that determines whether I need to specify 'dev' and 'version' on a package or some random trailing '1' or '0', but the first linux distro with a sensible and consistent naming scheme for packages is the one that wins my heart. `libgnutls-dev` `libgtk-3-0` `libwayland-server0` `libxcb1` `libx11-6` `libffi-dev` `libncurses5-dev`

Arch and its derivatives (mostly) don't have any of that. Though -dev means stuff only needed when developing against it. Number means major version number (so compatibility number). This way you can easily install multiple major versions as dependencies for different packages without clashing or breaking.

Arch Linux packaging is the only one that makes sense.

If I install openssl, I want everything that upstream ships, which means command line tools, headers, libraries, man pages.

The Debian/Ubuntu convention is terrible, and anachronistic. Disk space is cheap, my time is not.

Re: Make Apps for Linux

#323

Post by sph »

lupusreal wrote: post #56
alwayslikethis wrote: post #36

Earlier quoted context omitted.

There is a large intersection of Linux users and people who cherish their freedoms. For many people, using non-open source note taking software is a non starter because of the vendor lock-in and privacy concerns. Thus, you'll probably lose out more by not open sourcing the program than by open sourcing it and risk having some people not pay. I wager a lot more people is willing to pay than use proprietary software. A…

There are some programs that sell binaries but also give away the code. The premier pixel art editor Aseprite is free (source available, not open source) if you're willing to build it from source yourself, but most users buy the prebuilt binaries. I think this way you satisfy both the privacy conscious / cheapskates, and also the developer's economic needs. RMS doesn't approve I'm sure, but you can't please them all.

RMS totally approves, and selling binaries (as long as they are accompanied by source code) is explicitly approved by the FSF.

Open-source has never been about hating money or working for the glory.

Re: Make Apps for Linux

#324

Post by sph »

hnlmorg wrote: post #233
askonomm wrote: post #148

Earlier quoted context omitted.

KDE _functions_ well, but my god does it need someone with an actual design education to help out.

People with actual design education created macOS and Windows 11. Both of which strip back features in the name of design purity. I see KDE more like a professional piece of equipment. And when viewed through that lens, I think it’s designed rather well.

It is very naive to believe that professional equipment do not benefit from well-thought design and UX.

Design does not have to be fancy colours and flashy animations. Design does not mean Fisher-Price UI and massive amounts of whitespace. Ask Dieter Rams.

Re: Make Apps for Linux

#325

Post by zlg_codes »

chefandy wrote: post #255
zlg_codes wrote: post #229

Earlier quoted context omitted.

Look, business is about maximizing profits and minimizing costs. Business should absolutely not be looked to as an example of an entity that makes sane or suitable tech decisions over the long term. Their goals are different from everyday users, and both are different from power users and programmers. Why should normies suffer through worse software than those that know what they're doing? Web-based "native apps" are…

Reread what I wrote. I'm not saying they're sane technical decisions and I'm definitely not saying that electron is an objectively good architecture for user-facing apps, and I'm definitely not saying that profit is a good way to determine an ideal engineering strategy. But trying to discuss the viability of an option in real-word software creation without acknowledging that profits are often the driving factor in th…

Part of that is because profit should not take precedence when making a technical decision unless you are a business.

The other part is that if we accept only things that lead to easy profit, we'll avoid all sorts of things that take more initiative but become better products. Short-term stock price chasing is not a way to make tech decisions. It's a way to make profit decisions.

I seem to be on a website where nobody can picture doing anything without taking money from someone else.

Re: Make Apps for Linux

#326

Post by Zen1th »

This does ignore the fact that there's not one UI toolkit that you can target and that will work on all distros, and you certainly can't target Qt, GTK, ETK, etc. all at the same time. I've been making a cross platform GUI library and it's been a pain point on Linux (even though I use Linux!)

Re: Make Apps for Linux

#327

Post by pizza234 »

justin66 wrote: post #248
pizza234 wrote: post #217

Earlier quoted context omitted.

> If that's not stable, I don't know what is. What is? An immense amount of resources (developers) poured into developing live patches to make applications work on each newer version of Windows (or helping the application developers fix their applications). It's an interesting conceptual grey area - I don't consider it backward compatibility in a strict sense. This is documented in the book "The old new thing" by Ray…

> I don't consider it backward compatibility in a strict sense. Just in the sense that 100% of the people who use the phrase "backward compatibility" mean.

Sure, from a user perspective, but not from an operative perspective: in the cases of live binary patching, Microsoft required to call the application developer to be legally clear; in orther cases, APIs behave differently based on the executable being run. There's a lot more than just keeping the API stable.

Re: Make Apps for Linux

#328

Post by pizza234 »

Dalewyn wrote: post #237
pizza234 wrote: post #217

Earlier quoted context omitted.

> If that's not stable, I don't know what is. What is? An immense amount of resources (developers) poured into developing live patches to make applications work on each newer version of Windows (or helping the application developers fix their applications). It's an interesting conceptual grey area - I don't consider it backward compatibility in a strict sense. This is documented in the book "The old new thing" by Ray…

It's because Microsoft understands and respects that computers and operating systems exist to let the user achieve things. The user ultimately doesn't care if his computer is an x86 or an ARM or a RISC-V, or if it's running Windows or Mac or Linux or Android. What the user cares about is running Winamp to whip some llama's ass, or more likely opening Excel to get work done or fire up his favorite games to have fun. M…

This has very severe drawbacks, so it's not unambiguously desirable.

Windows APIs are probably a mess because of this (also ignoring the fact that only company with extremely deep pockets can afford this approach). There is at least one extreme case where Windows had to keep a bug, because a certain program relied on it, and couldn't be made to work otherwise.

Re: Make Apps for Linux

#329

Post by mkup »

arp242 wrote: post #300
Dalewyn wrote: post #202

Earlier quoted context omitted.

It really is mindblowing that Windows 11 is still capable of running 32-bit programs written for Windows 95 , that's 28~29 years of backwards compatibility and environmental stability. If we look back to programs written for Windows NT 3.1, released in 1993 , and assume they run on Windows 11 (because why not?) then that's 30 years of backwards compatibility. Did I say mindblowing? It's downright mythological what Mi…

Linux can do this; binaries from the 90s work today. Something like xv (last release: 1994, although the binaries were built against Red Hat 5.2 from 1998) still work today, and the source still builds with one very minor patch last time I tried it. The problem running the binaries is: % ldd ./usr/X11R6/bin/xv linux-gate.so.1 (0xf7f82000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7e22000) libjpeg.so.62 => not found l…

Much of the Windows compatibility is "just" stable API for Windows controls, GUI event handling loops, 3D graphics and sound (DirectX). Linux has stable API for files and sockets (POSIX), but that's all.

Re: Make Apps for Linux

#330

Post by mkup »

FirmwareBurner wrote: post #231
EvanAnderson wrote: post #208

Earlier quoted context omitted.

NTVDM could have been ported to 64-bit Windows, but MSFT declined to do so. Leaked Windows source code shows it would have worked[0]. That would have given 16, 32, and 64 bit compatibility. [0] https://github.com/leecher1337/ntvdmx64

I don't get it. Would NTVDM have been better than say, using DOS-box?

Yes, it would allow to create pipes between 16-bit NTVDM processes and native 64-bit processes.
Post reply on HN