Live data from Hacker News

Make Apps for Linux

makealinux.app

231–240 of 422 posts

Re: Make Apps for Linux

#231

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…

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?

Re: Make Apps for Linux

#232
post #34

I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management ins…

People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed web-based plumbing is a bigger win for Linux users than supporting only windows and macos where like 97% of desktop users are.

I like to shit on electron because plain old tcl/tk is a better/leaner alternative. Apart from the myriad of other[0] alternatives that exist.

[0]: https://github.com/sudhakar3697/awesome-electron-alternative...

Re: Make Apps for Linux

#233
post #68

Earlier quoted context omitted.

Personally I think KDE is light years ahead of macOS and Windows. In fact I find macOS to have been be of the worst window managers of all the popular platforms (sure it’s pretty and easy to use, but trying to do anything beyond the basics requires magical incantations that are impossible to discover organically). Each to their own though.

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.

Re: Make Apps for Linux

#234

Earlier quoted context omitted.

on your ‘com’ site mentioned in github page download button does not offer (near by) payed options. Why? Why it is only in the separated Pricing link? Why not to present the same choice in download ?

Thanks for your remark! I never thought about it. I suspect it will drive down the number of downloads? How do you think it will be beneficial?

I think it could be beneficial because it would be easier for those who wish to pay. They would not have to do extra step looking for that opportunity.

I personally do not like (in soft words) when button says one thing and delivers something else. So I think renaming Download into ‘Download options’ were you give choice download ‘ free’, ‘donate’, ‘pay for pro’ etc as you like is acceptable and feels good enough. I do not see why in that case it should reduce number of downloads but every prediction is always a prediction and nothing is better then the real life test.

Re: Make Apps for Linux

#235

Earlier quoted context omitted.

Stuff like Flatpak and Snap exists because the framework side kinda is built-out. Isolation technology had matured, newer desktops emphasized per-window security and needed APIs to portal in and out of each instance. The desktops needed a packaging/infrastructure solution to tie that together and make it presentable to the user.

Yet I still can't compile an app on some arbitrary release of some arbitrary distro and just run the darn exe on another and be 100% sure it will work.

The trouble is you're trying to distribute it as a binary yourself. The there are two traditional ways for distributing software for Linux:

1) The system package manager. It will download a binary from the repository which is the right one for that system.

2) make && make install. This is mostly for software in development that hasn't made it into the package manager yet. It will compile from source and produce a binary for the target system.

All the problems are from people trying to do something other than this.

Re: Make Apps for Linux

#236
post #221
post #80

Earlier quoted context omitted.

Cuplrits are mostly glibc devs with their manic abuse of version names (and very recently, a GENIUS who added a new ELF relocation type): this is a pain for game developers to provide binaries which span a reasonable set of distros in time. Basic game devs install one of the latest mainstream and massive distros, build there, and throw the binaries on steam... but that recent distro had a glibc 2.36 and now their bin…

Isn't the solution to this problem to just distribute the source code. Let package maintainers worry about creating binaries for their distros.

not when you actually want to sell the games for money.

Re: Make Apps for Linux

#237

Earlier quoted context omitted.

>Win32 (via Wine or Proton) is the most stable target for Linux right now Tangential, Winamp 2.xx from the '90s runs and plays MP3s just fine on Windows 11 today. There are better apps for that today, but I still use it because nostalgia really whips the llama's ass. Pretty wild that the same thing is not the norm in other OSs. Even wilder is that I still have my installed copy of Unreal Tournament 99 from my childho…

> 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.

Microsoft respects that, and so strives to make sure Windows is the stepping stone users can (and thusly will) use to get whatever it is they want to do done.

This is fundamentally different to MacOS, where Apple clearly dictates what users can and cannot do. This is fundamentally different to FOSS, where the goal is using FOSS and not what FOSS can be used for.

It's all simple and obvious in hindsight, but sometimes it's the easiest things that are also the hardest.

Re: Make Apps for Linux

#238

Earlier quoted context omitted.

The most underrated feature of windows probably ever.

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…

Personally I've had little luck with even running XP applications on Windows 7. More generally, going by the difficulties experienced by many companies and organizations in the transition from XP->7, it's hardly an isolated problem. Perhaps Windows maintains the best backwards compatibility of any mainstream OS, however I would hardly describe it as "mythological".

Re: Make Apps for Linux

#239

Earlier quoted context omitted.

People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed web-based plumbing is a bigger win for Linux users than supporting only windows and macos where like 97% of desktop users are.

Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java. Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework. So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?

when i see a java application i think, hmm, this is likely going to be bloated (but not necessarily) but for sure it's going to run.

if i want to create a cross platform application where i don't even have to think about testing on multiple operating systems, then java is going to be a serious contender.

and if i have to choose between an app written in java or electron, i'd probably pick the one in java.

so yeah, i don't understand what happened here either.

Re: Make Apps for Linux

#240
post #80

Earlier quoted context omitted.

Cuplrits are mostly glibc devs with their manic abuse of version names (and very recently, a GENIUS who added a new ELF relocation type): this is a pain for game developers to provide binaries which span a reasonable set of distros in time. Basic game devs install one of the latest mainstream and massive distros, build there, and throw the binaries on steam... but that recent distro had a glibc 2.36 and now their bin…

> But you have engines really not ready, for instance electron based games: you don't have the right version of the GTK+ toolkit installed on your enlightenment/Qt/raw X11/wayland/etc distro? Nah, won't run. Hm, not sure what you mean here. At least with the nw.js toolkit (from which Electron was forked IIRC) I've never gotten a report of a distro where it would refuse to run because of an incompatible GTK version.

Why would a distro have GTK in the first place?

More reasonably, binary GUI apps should not expect more than the window system, on elf/linux, wayland with a legacy fallback to x11. It means, the GFX toolkit is an application choice on top of the windowing system. Binary GUI apps have to distribute it... they have to distribute their own version which would not conflict with the version installed on the user system... if any...

Post reply on HN