Earlier quoted context omitted.
What's the standard for being an "actual Windows user"? Asking because I doubt e.g. my mom knows that NTFS has symlinks.
Egads, if the parent post wasn't edited, then I misread it. Sorry about the confusion.
Cross-compiling binaries for Windows is easier than building natively
281–290 of 349 posts
Re: Cross-compiling binaries for Windows is easier than building natively
#282Earlier quoted context omitted.
Rather it's their baroque ACL permission system, which is not able to cache inherited perms.
The ACL permission system is in NTFS. For example FAT32 doesn't have it.
Re: Cross-compiling binaries for Windows is easier than building natively
#283It is. I generate the Windows executables for a program by cross-compiling Rust on Linux. Then test with Wine. The Rust crates are cross-platform enough that I don't have to special case platforms. This is easier than having a Windows machine. The only current headache is that there's no pure Rust bundler, to make ".msi" or ".msix" installer files. If you dump the legacy OS stuff, it gets easier.
I also cross compile and remote debug windows software on Linux (C and Rust programs). Using gdbserver --multi (extended remote mode) is quite comfortable. The biggest advantage is not having to use different tools for different target platforms. Unfortunately MacOS is more difficult target than Windows. If anyone has tips for compiling and debugging software of MacOS from a Linux host, please do share.
Re: Cross-compiling binaries for Windows is easier than building natively
#284Earlier quoted context omitted.
NSIS (Nullsoft Scriptable Install System)[1] can be compiled[2] for Linux if that's any help. I use that to prepare the install .exe package for a Java based program for one of my clients. [1] https://nsis.sourceforge.io/Main_Page [2] E.g.: https://aur.archlinux.org/packages/nsis / https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nsis
NSIS is not a substitute. It's good for shipping to home users, but msi installers are essential for enterprise software distribution.
Re: Cross-compiling binaries for Windows is easier than building natively
#285It is. I generate the Windows executables for a program by cross-compiling Rust on Linux. Then test with Wine. The Rust crates are cross-platform enough that I don't have to special case platforms. This is easier than having a Windows machine. The only current headache is that there's no pure Rust bundler, to make ".msi" or ".msix" installer files. If you dump the legacy OS stuff, it gets easier.
I also cross compile and remote debug windows software on Linux (C and Rust programs). Using gdbserver --multi (extended remote mode) is quite comfortable. The biggest advantage is not having to use different tools for different target platforms. Unfortunately MacOS is more difficult target than Windows. If anyone has tips for compiling and debugging software of MacOS from a Linux host, please do share.
Re: Cross-compiling binaries for Windows is easier than building natively
#286Re: Cross-compiling binaries for Windows is easier than building natively
#287Earlier quoted context omitted.
*>My IDE install is about 25GB Would love to see a breakdown of where that space is going. FWIW IntelliJ takes up 2.5GB, and honestly, even THAT seems like a lot to me.
I have no idea sorry! On the Jetbrains front that's interesting. My Intellij folder is closer to 4GB, but that's only for one language. I've also got Rider and Goland installed, and Jetbrains duplicates the entire install per IDE. My Jetbrains folder is 12GB. > even THAT seems like a lot to me. That's a little silly - what is an acceptable amount in that case. The JDK on its own is about 700MB (that's a guesstimate b…
25GB is enormous. 2.5GB is enormous. Consider that the core value of this software is text editing. Consider that not long ago people were buying PCs with perhaps 10MB of hard disk - or even no hard disk at all (e.g. the Apple IIe). Windows XP and Office 97, for example, were (if memory serves) less than 1 GB total. FoxPro for DOS was something like 4 megabytes - and FoxPro was a form builder plus relational database. Consider that with a thoughtful use of resources and an eye toward minimizing attack surface, you can put a fully functional http/s app server in a 1.9MB package (redbean).
These sizes are silly, and they should give you pause. The space is cheap, yes, but the attack surface is not.
Re: Cross-compiling binaries for Windows is easier than building natively
#288I agree that symlinks cause more trouble then is needed on any platform. Sadly, only Node really likes to use them to optimise the store of packages Personally, I don't have major issues compiling things on Windows for other platforms (macOs, Win32, Android, Linux). Only awkward thing is designing UIs
I don't think that's what they sre saying, I think they sre saying it's stupid Microsoft requires hoops for such a basic feature, hence "Fix Windows" being option 1
Symlinks are a premature optimization in my book, or worse, bad design. On the user level, shortcuts are often the better solution, because they allow arguments to be passed in on the command-line.
This story is really about the arrogance that is as abundant as it is inappropriate in linux world. Never have I heard of dependency hell or broken systems on Android, yet geriatric linux always needs the help of an administrator.
The only place where linux still has some merit is on the server, where its classical but aging mainframe concepts still have some life left in them.
Re: Cross-compiling binaries for Windows is easier than building natively
#289And slash. They got it backwards.
/ is used both in writing and in Maths. \ is a character used almost exclusively in programming. From a practical point of view, I find \ to be a much more suitable directory separator than /, for the same reason I think Microsoft's choice for blacklisting characters like ? and : from file names is silly. There are real world use cases [1] for adding the / to file names so it shouldn't be excluded! Microsoft has used…
There was even an option (in CONFIG.SYS) to alter the 'switch character', which then also caused a lot of command line tools to accept '/' for paths. That option was eventually removed from the config file, but the underlying API retained until quite late. Maybe it was WinME's version of DOS which disabled the API.
Despite all of that, the handle based Int 21 file APIs always supported being passed '/' as a path separator, and it was often accepted by some apps.
DOS based 'C' source code often used "#include ", however many compilers also simply accepted "#include ", probably just as an artifact of the obvious implementation. This wasn't well known, so lots of DOS based 'C' source used '\\' in includes, plus also at the file API level.
Re: Cross-compiling binaries for Windows is easier than building natively
#290Earlier quoted context omitted.
I have no idea sorry! On the Jetbrains front that's interesting. My Intellij folder is closer to 4GB, but that's only for one language. I've also got Rider and Goland installed, and Jetbrains duplicates the entire install per IDE. My Jetbrains folder is 12GB. > even THAT seems like a lot to me. That's a little silly - what is an acceptable amount in that case. The JDK on its own is about 700MB (that's a guesstimate b…
We are two wealthy people arguing over rents, with you saying $1M/month is reasonable, I'm saying it's not, I'm only paying $100k/month, meanwhile most of the world is paying on average $100/month. 25GB is enormous. 2.5GB is enormous. Consider that the core value of this software is text editing . Consider that not long ago people were buying PCs with perhaps 10MB of hard disk - or even no hard disk at all (e.g. the…
Don't be reductive - just because your linux hides those costs directly in /usr and /var it doesn't mean those things don't exist.