ELF loading
in [ASM]
|
From: Betov on 27 Aug 2007 06:56 CodeMonk <jascwa(a)yahoo.com> �crivait news:JMxAi.654$Y7.422 @bignews3.bellsouth.net: > I did say it was a skilled offering. But, and this is just my > opinion, I think you are shooting yourself in the foot with the source > in the executable concept. If for no other reason than it's a > security risk and I'll just mention in passing the fact that Wannabee > is a contributor of some of RosAsm's executables. _Facts_. No "opinion, on such points. Facts are that nesting mono-files inside the executables has been a complete success. First it makes all managements extreemely simple and secure. Second, we have never heard any RosAsm user saying that he would have lost his sources. Third, this is the perfect distro model for GPLed Apps. Fourth, there are all required features for saving the Sources. Including incremental savings. So, what do have to say against? Where is the "security risk"? As opposed i can fairly well tell you were the security risks are with traditional methods. Do yo need examples of programs which Sources are lost?! > Keep in mind that a Unix person would consider Windows > counter-intuitive. AKA - the humorous Mac / Windows debate. I am used to Linux exploring since the earlier days, mind you. Betov. < http://rosasm.org >
From: Robert Redelmeier on 27 Aug 2007 06:58 Herbert Kleebauer <klee(a)unibwm.de> wrote in part: > Betov wrote: >> as opposed to most believe, there is absolutely no reason >> why a good GUI should be any slow. Is MenuetOS GUI slow? >> No. So, having Linux made slow in GUI mode does not make >> any sense, as an argument. It is slow. Period. > > Then try http://www.xfce.org > or http://www.fluxbox.org Those are faster, but my fundamental objections to GUIs aren't about speed: 0) GUI pgms are harder to write than console apps. GUI users are harder to teach to program. GUIs are a learning crutch which tends to hobble more advanced users. No upgrade path. 1) All GUIs are fundmentally menuing systems. Limited choice. You can only run whatever has been configured. If you can find it. My $PATH has 2995 executables on it. A very busy GUI max 100. 2) GUIs are bloated bugfests. Poor use of hardware. A small example -- I view text 160 cols by 73 rows in crisp textmode fonts. I can't tune an Xterm to more than 132x50 before the fonts become badly interpolated in bitmode. 3) GUIs abandon that great IT invention of 7000 years ago -- the alphabet! Icons are cryptic pictographs. 4) GUIs don't permit pgms to co-operate. How do you do a pipe | ? The clipboard is a feeble sustitute, and is available as `gpm` under CLI. 5) Most GUIs are very poorly implemented, with poor UI choices, and excessive mouse precision required. In fairness, many CLI are also poorly implemented. MS-Windows COMMAND.COM is horrible, and CMD.EXE is only marginally better. 6) Most GUIs make excessive use of the mouse which tends to cause Repetitive Strain Injuries (carpal tunnel). Tasks are hard to describe, automate (scripting?) or repeat (history?) Please note I'm not picking out any particular GUI. MS-Windows, The X Window System, or Mac OS X are all roughly equally bad. -- Robert
From: Herbert Kleebauer on 27 Aug 2007 07:07 Betov wrote: > Herbert Kleebauer <klee(a)unibwm.de> �crivait > > Then try http://www.xfce.org > > or http://www.fluxbox.org > > > > instead of KDE/Gnome. > > Second link "silent", here. Here it works. Now that you have Linux, try traceroute www.fluxbox.org (from the command line!!!) or "tracert www.fluxbox.org" on your Win2k (also from the command line!!!) to see why you can't connect. > The first one look nice, but... no thanks. If Gnome is choosen > by Ubuntu, and if Ubuntu wins, there is no use and no room for > any alternative GUI. What is needed, if slowyness is because of > Gnome, is to make Gnome responsive. Not my problem, actually. Why do you think, if Ubuntu still exist in two years, they will still use Gnome and not KDE?
From: Herbert Kleebauer on 27 Aug 2007 07:16 Betov wrote: > CodeMonk <jascwa(a)yahoo.com> �crivait news:JMxAi.654$Y7.422 > _Facts_. No "opinion, on such points. Facts are that nesting > mono-files inside the executables has been a complete success. > First it makes all managements extreemely simple and secure. Just a question: are the executable and the embedded source always at the same version level? What happens when you modify the source in a way that it produces a compilation error, can you then not save the source or is the source saved without a binary?
From: santosh on 27 Aug 2007 08:23
Betov wrote: > CodeMonk <jascwa(a)yahoo.com> �crivait news:JMxAi.654$Y7.422 > @bignews3.bellsouth.net: > >> I did say it was a skilled offering. But, and this is just my >> opinion, I think you are shooting yourself in the foot with the source >> in the executable concept. If for no other reason than it's a >> security risk and I'll just mention in passing the fact that Wannabee >> is a contributor of some of RosAsm's executables. > > _Facts_. No "opinion, on such points. Facts are that nesting > mono-files inside the executables has been a complete success. > First it makes all managements extreemely simple and secure. > Second, we have never heard any RosAsm user saying that he > would have lost his sources. Third, this is the perfect distro > model for GPLed Apps. Fourth, there are all required features > for saving the Sources. Including incremental savings. BTW, do you compress the sources in your final PE? |