Conversation
Notices
-
- Popa Adrian Marius likes this.
-
-
@mtrausch you want a list? http://blog.flameeyes.eu/tag/fatelf
Popa Adrian Marius likes this. -
@flameeyes: Most of that list seems to boil down to "we don't want any". I agree its target would be small—but it would still have some use.
-
@mtrausch no, you should try to understand what's written there before saying so. You'll have to make a *huge* effort for *no* benefit.
-
@flameeyes I do understand the list, as well as how binaries work and static and dynamic linkers. The benefit would be little, not none.
-
@flameeyes That said, your most recent message shows that you do not desire logical conversation; therefore, I'm done with this thread.
-
@mtrausch: you can name a single benefit and then we'll see who's rejecting logic here...
-
@flameeyes: Just b/c you don't care abt it doesn't nullify its benefit in saved time/effort. (Further, excess could be stripped @ install.)
-
@mtrausch how, and where? as it was presented you needed a special kernel and loader to load files that are as big as the N counterparts...
-
@flameeyes: If you cannot ack the potential benefit as I just stated, we do not have anything else to talk about WRT any type of fat binary.
-
@flameeyes: Or, for that matter, managed code systems such as JVM and CLR.
-
@mtrausch you have not stated _any_ potential benefit. You handwaved "its benefit in saved time/effort"! And I'm the non-logical one? Pfft.
-
@flameeyes Tell him it doesn't count if you don't stamp your foot and say, "So, _there_!"
-
@flameeyes: Compile once, run on multiple platforms isn't a benefit? Why does managed code exist, then, hrm?
-
@flameeyes: Now, I will grant that it benefits companies that want to deploy custom systems, and not much else. Still a benefit.
-
@flameeyes: A modified toolchain would automate it, from the human POV, it'd be compile once.
-
@mtrausch you can do that already, write a cc frontend that compiles the same file multiple times, it's _not_ hard, I've done it before
-
@flameeyes: I didn't claim it was managed code. I said it could be used to solve a similar problem w/ less overhead. I'm not speaking Greek.
-
@mtrausch I have also elaborated on a possible alternative to basically have the same execution effect without having to change N layers
-
@flameeyes: But you then still have multiple binaries to ship. That solves nothing at all. Shipping 1 is better than n when n > 2 or 3.
-
@mtrausch if you still think that writing build&install frontends is harder than changing N OSes and M architectures with P layers...
-
@mtrausch how is shipping one (fat) binary "better" than shipping one auto-extracting auto-deciding archive?
-
@flameeyes: Mods to kernel/toolchain would be req'd, yes. Not unlike any new feature in the same area in the last 20 years.
-
@mtrausch you can achieve *the same* benefits at a millionth of the cost
-
@flameeyes: Your suggested solution is not able to be XIP.
-
@flameeyes: That is, it requires custom, ad-hoc SW that would be dup'd on disk and requires a place to put binaries w/ user privilege.
-
@flameeyes: I'm sorry, but how is duplicated ad-hoc systems less heavyweight than centralized code that reads modified ELF files?
-
@mtrausch custom, ad-hoc _user_ software would be so much worse than N custom ad-hoc KERNELS?
-
@mtrausch because in 99% of all the usage, the kernel won't _need_ it. And its cost in effort and overhead would be higher.
-
@flameeyes: If it were a feature incorporated into mainline, how would that be ad-hoc? You seem to intentionally be missing the point here.
-
@mtrausch it still would require a feature used by a small number of "software distributors"; half the people would never use it
-
@flameeyes: It also sounds to me like you have never looked at disassembled code before. A branch has negligible overhead if not followed.
-
@flameeyes: Invalid justification; many kernel features are specialized/tailored for extremely small subsets of users.
-
@mtrausch yeah I never looked at disassembled code, I've been doing multimedia _and_ embedded work for years, who am I to talk about this uh
-
@flameeyes: Then why do you make a claim that is nonsensical in practical programming terms? Look around the kernel tree a bit, eh?
-
@mtrausch it's code that's going to be rarely useful it at all, it's design is too intrusive and there are numbers of alternative approaches
-
@mtrausch case in point: if you sacrifice dynamic linking (and in the field of use you described it makes sense), you can forgo a loader
-
@flameeyes: Here, because 140c just isn't enough: http://is.gd/d11Rb
All Identi.ca content and data are available under the