|
I particularly thank Noam for the intellectual spawn of "colorless green ideas sleep furiously."
Also really appreciated that Noam begat Pinker who could actually describe some of Noam's linguistic theories in a form mere humans could understand, and who has the courage to argue against some of them.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
So I wanted to use a piece of software written in C(++?).
As a user, I shouldn't really care what it's written in, except that when I want to use it on anything else but a Mac I have to build it myself... 
I've seen that more often, although there's usually a Windows installer as well, but not this time.
Screw that, I'm not using a tool that's supposed to help me except it first makes me work for it.
I believe this is standard practice for everything ever written for Linux, but what's the idea behind having to build it yourself? 
Why do the developers not simply build it for me (and thousands of others) and save me some trouble?
Why would a user ever want to build it himself? 
I'm sure "because we're 1337 and you're a n00b" isn't the only reason although it's the first that comes to mind 
|
|
|
|
|
Quote: Why would a user ever want to build it himself?
Because he wants to modify the sources according to his needs.
Or, more reasonably:
because his platform (e.g. an embedded system) is not directly supported.
|
|
|
|
|
In this case I'm looking at a static code analyzer, not something you'd use on an embedded system
I'm guessing a default Windows installer would suffice for 99.9% of the user base.
CPallini wrote: Because he wants to modify the sources according to his needs.
That's a good reason, although I wonder how often that really happens.
It seems silly to have build-it-yourself as the only option though.
|
|
|
|
|
Or equally reasonably,
the developer does not have access to the OS that you are running.
Do you have access to:
Windows 10
Windows IoT
MacOS
Linux x86-64,i386,arm32,arm64 rpm format
Linux x86-64,i386,arm32,arm64 deb format
Then there's all the minor players like pacman on Arch Linux, AmigaDOS, (Net,Free,Open)BSD, Haiku etc.
Chances are that if you provide a useful tool in source code, somebody will figure out how to compile it on their system and, hopefully, feed the changes back to you, or at least make them available to others
|
|
|
|
|
 sounds dangerously like common sense !
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
So it should be an option, which a lot of windows programmers give you, with a separate "download source" link.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
it was common on linux because of different platforms, c/c++ compiles down to native machine code and linux (more so unix) runs on many different hardware from PDP to IBM. Even on the same architecture a lot had to be handled before compiling such as byte order, sizeof's (32/64 bit ints)....
the unix way was also often "here's my answer, feel free to take it as is, or improve it for yourself/purpose.
a lesser (later) reason was the "what's really inside" worries - compiled to native even decompiling/disassembling didn't tell you much (or being assembly told you way too much in painfully simple detail... MOV 1 A, CMP A B... 325,000 lines, is there a trojan in there somewhere?).
when windows came out compilers were both expensive and uncommon but it was only one architecture (ms introduced it's own hacks for 32 bit code on 64 bit machines) so giving compiled code was fine as long as you trusted the author/download site (and enough others had tried it and didn't get ransomwared.)
A few unix folks jumped into some windows dev, their habits often didn't change (i.e. provide the source: use as is or mod it yourself.)
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
|
|
|
|
|
A remnant from ye olden days!
Building software back then sounds like a real PITA...
I really wish those Unix devs got with the times and gave me an installer though 
I'm really not going to download the C/C++ tooling just so I can try out this one tool.
To be fair, I'm not a C/C++ developer, which is who this tool is for.
I just need it to test some functionality of another tool, but I'm just going to take their word for it 
|
|
|
|
|
Nowadays, there are lots of naive peope cheering "Containers! Docker! Hallelujah!", believing that once you have put the stuff into a container, it is "build once, run anywhere!" Sure...! The interface between host and the running container is, at the functional level, reasonably simple; it is realistic to implment it on "any" architecture. But inbetween the host/container interactions, the container is on its own - together with the CPU, of course.
When Apple jumped from 68K to x86, they developed an emulator for running 68K code on the x86 that was surprisingly efficient. There is nothing like that in the Docker container. If the machine code inside the container is x86, the CPU better be x86, too! "Run anywhere, provided that you are on an x86" is sort of "You can have the T-Ford in any color you want, as long as you want it it black". Lots of Docker affectionados haven't realized that yet.
Obviously, the host may - outside the container - provide an emulated CPU by having, say, a PPC cpu interpret in software every x86 instruction code. You could hardly describe that as "lightweight" virtualization! And for it to be universally "run anywhere", every Docker host would have to be able to emulate any instruction set that might be found within a container.
I wonder if MS is working on containerization where the code inside consists of dotNet assemblies, compiled on-the-fly to the native code of the host. That could be (part of) a solution for truly build once, run everywhere. (The CLR sort of provides (parts of) this, but without the container protection.) I think that Docker containers will live for many years, but it is certainly not the last word in container technology. My guess is that the container/host interface in future techologies may include some JIT code generating, so that the container at startup (/JIT) deliver something like an assembly to host and get the native binary code back for execution in the containerized enviromment. That will probably be in a container framework different from today's Docker, though.
|
|
|
|
|
The real reason is that everyone and his kid brother have taken Linux, and bent/folded/stapled it so that it is incompatible with any other version (including those compiled for the same hardware). In other works, there is no agreed ABI which guarantees that a shared library compiled for x64 on one system will run on another x64 system.
In this jungle, the only way to ensure that code will work is to compile it locally. If the code compiles (sometimes - this is a big if...), it will probably work on your machine. Otherwise, you're SOL.
Note that even compiling without error is no guarantee of proper working - see Chemists bitten by Python scripts: How different OSes produced different results during test number-crunching • The Register
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Sander Rossel wrote: I wonder if the same goes for multi-platform .NET Core
I think so ... unless you need a user-interface with some more-than=stupid controls on it that are not grafted on by running a browser under the hood 
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
|
Sander Rossel wrote: Especially the DataGridView was a horror to work with
It still is... 
"When you are dead, you won't even know that you are dead. It's a pain only felt by others; same thing when you are stupid."
Ignorant - An individual without knowledge, but is willing to learn.
Stupid - An individual without knowledge and is incapable of learning.
Idiot - An individual without knowledge and allows social media to do the thinking for them.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
Sander Rossel wrote: That rules out any controls .NET has to offer
Hi Sandor,
Let me clarify my comment: imho, in this later stage of personal computing where rich user interfaces are the norm, the Catch-22 of any attempt at having a multi-OS dev solution is that really rich, complex, controls ... not buttons, checkboxes, monofont textboxes ... probably need to access OS dependent facilities under-the-hood for platform-centric look-and-feel, for rendering speed and fidelity.
The emergence of web browsers driven by JavaScript as a lowest common denominator solution for multi-OS apps is the major current solution, but, that means your not-a-web-app has to add a browser engine, and interact with it to invoke the platform-dependent goodness.Sander Rossel wrote: I remember the WinForms controls were not even half-decent
imho, for their time, they were useful, and free, and their limitations drove a thriving 3rd, party control industry, as well as many wonderful CP articles.
cheers, the old fossil, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Safe and protective in that so long as you don't venture out all the parts (at least in theory) work together and consistently.
Perhaps modify that to .NET on Windows - or may .NET on WindowsN. For, you see, code I wrote for XP didn't quite work on 7 - but I got it to work. But them more changes came about - Win7 on VMWare started to stop working.
If one stays completely in a single world it becomes, as Candid was taught by his mentor, Pangloss, 'since this is the only possible world then it is the best of all possible worlds".
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Quote: The real reason is that everyone and his kid brother have taken Linux, and bent/folded/stapled it so that it is incompatible with any other version
Amen.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
The sense of accomplishment?
Because he wants to see how many compiler warnings the developer is ignoring?
Because he can check the code carefully to ensure it doesn't contain ransomware?
Because he's desperate to find anything that runs on Linux? 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Quote: Because he's desperate to find anything that runs on Linux?
It could be worse. It could be PIC32.
|
|
|
|
|
Quote: It could be worse. It could be PIC32.
Do not even joke about it!
|
|
|
|
|
Don't be sad, you should rather enjoy the development on PIC32 and his cousins!
|
|
|
|
|
It's the whole 32 bit thing threw me when I wasn't aware of it...
|
|
|
|
|
I find it (programming for 32 bit MCUs, compared to programming for 16 and 8 bit ones) simplier. I really enjoy C++ with PIC32.
|
|
|
|
|
I got it dumped on me due to the previous guy leaving, didn't really have time to use it properly, I was doing 4 bit (support), 8 bit & 16 bit... really ought to look at it again when I have time.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
