Older blog entries for mslicker (starting at number 62)

12 Apr 2004 (updated 13 Apr 2004 at 02:17 UTC) »
badvogato, Picking your battles is all I had in mind. Debate, the exchange of ideas, for these things to have any meaning requires cooperation of the parties involved. If nothing else, chalst's comment is encouraging.

We are making progress, Chuck had released his network code. I have extended it with DNS and DHCP, with TCP in the works. Some of this progress can be seen here. Chuck is working on a new version with colorForth in colorForth, USB support. There have been dicussions on a Forth Markup Language (FML).

5 Apr 2004 (updated 5 Apr 2004 at 23:48 UTC) »
badvogato writes an interesting article and makes a insightful observation. I think this is the wrong forum however. colorForth is a radical solution, it proposses an alternative wholly seperate from the work of this community, it does not fit the framework of GNU, Linux, C, ect. People like to have knowing comfort in their methods and their work. I think for many, Forth in its radical form presents a discomforting disturbance to their world view, for them it should not exist, it must be buried from sight.
ML and Forth

I think ML semantics could be implemented in Forth, the main concept that would be needed is a local envrironment. Forth, at least the one I use, only has a global environment.

Map in Ocaml:

let rec map f l = if l = [] then [] else f (hd l) :: map f (tl l)

could be expressed:

: map {l f} l [] = if [] else l hd f a f l tl map :: ;

a would be the apply function. {l f} would denote a binding, binding the top stack element to l, the second stack element to f. In colorForth, :, {}, ;, could be replaced by color.

I don't have any interest in seeing this through at the moment, just a thought for now.

ncm, I don't think you understand, what I have done is not to implement Ocaml in Ocaml, I have expressed a simple recursive function which happens to be a library function.

Ocaml includes "map" as a function expressed in Ocaml, here is how they define it:

let rec map f = function
    [] -> []
  | a::l -> let r = f a in r :: map f l

I not quite sure why they do it this way, I think they use pattern matching because of the the builtin error reporting, let r = f a in r :: map f l could be expressed: f a :: map f l .

Any fool can criticize, condemn and complain and most fools do.

--- Benjamin Franklin

I'm looking for the origin of an idea. The idea is that all proprietary software should a have a "free" (RMS definition) equivalent.

This idea is very pervasive within the free software community. My thought is that it originates with Stallman. He says the only aspect of software that matters is whether it is free or not. Therefore the problem with Microsoft Windows is not that its purpose is to extract maximum profit in the market place, but that its users cannot freely make changes to it and share those changes. It is small leap to say a proprietary software with large user base should have a free equivelant.

On the other it might be purely a strategy of a certain kind. If you create free equivalents, you bleed the company producing the proprietary software of its revenue source. In the process, according to a certain line of thinking, you promote free software and expand its application base.

A third possibility is that people are so ingrained with the ideas and concepts proprietary software, creating something original is beyond their capacity.

A forth possibility is that knock offs are created for the same reason proprietary software companies create knock offs. Similar software can ride the popularity of existing popular software.

Even if no one has explictly sugested this idea, there may be sufficient reason for it to be implicitly accepted. The obvious problem is that at the end of the day proprietary software companies have defined the adgenda for free software. The fundemental purpose of proprietary software is extracting profit in the market place. This is not deny there may be interesting and original ideas in proprietary software nor that the developers of the proprietary software have talent. However, I don't see free software reaching a fraction of its potential until it can succesfully break free of the proprietary software establishment.

chalst, Apology rescinded. You only use my apology further vent your anger toward me. Why I am singled out for a run away disscussion, which includes the pontification of a well known troll, is only hinted at.

In end it appears to be political difference which constitutes your anger toward me:

"I don't think these opinions are in bad taste. I think they are very badly wrong"

That thread comes to a truely absurd point when you nominate the troll, and neo fascist as Advogato's most decent human beings.

I take partial responsibility for the argumentative direction of chalst's article. Apologies to chalst.

GNU/Linux

I'm beginning to reconcile myself with GNU/Linux. In particular I think it is perhaps the ultimate legacy system. Making a system compatible with every exisiting public and proprietary standard is no easy task and certainly not a desirable one. Even if the mind set is still within the proprietary realm, the software is generally more friendly, open and acessible. GNU/Linux is certainly a positive result and a step in the right direction.

colorForth

With colorForth I decided to move the editor out of the kernel. The editor is the only application included in the kernel and requires graphics and input available in the kernel. With the editor in colorForth source, there is more flexibility in implementing the graphics and input. Besides this colorForth will be easier to port, as the editor is currently a signifigant application implemented purely in x86 assembly.

With editor in source, I'd like to implement the graphics in GLX/OpenGL and the input in X11. This will result in one C file which will be the bridge from the archaic disorderly world of Linux to the orderly logical world of colorForth. I think the words implemented in C will simply be passed to colorForth as a symbol table. This way C can handle all the linking and loading of libraries. This is also how XcolorForth works, except C words do not become part of the dictionary.

The point of all this, is that colorForth will be suitable for C platform applications while keeping the simplicty and interactivity of native version. The troubling part is of course all these layers of complexity that are present, and all the possible bugs that are not related to your code. Of course this is the result in any C platform based application development. Abstracting from the C functions at least the colorForth code can be easily ported from compromised state to the native state.

2 Sep 2003 (updated 2 Sep 2003 at 19:58 UTC) »
Performance

The motivation for high performance software should be obvious. The less computational resources required by software, the cheaper hardware can made to support this software. The cheaper hardware is the more affordable it is to those with less wealth. This is something that completely bypasses the consideration of wealthy people in countries like the United States who enjoy an abundance of computing power. If the Free Software movement has any precepts regarding democracy, it should lower the computational hurdles of its software. An additional benefit to stagnating or decreasing computational needs is that computer hardware will have a longer life, and therefore the environmental impact of largely disposable computers will greatly decrease.

A good way to achieve performance in software is to make things simple. This idea did not originate with me, its echos can heard from the giants of computing. I'm in the process of rewriting my jpeg decoder. Analyzing the common types of images distributed, I was able to simplify the decoder in a way which yielded a 30% increase in performance. I now have less code, and a superior result. With simplicity comes transparency. Any software sympathetic to democracy should be transparent, that is the operation and structure should be as readily apparent as is possible.

I think an emphasis on democracy would be a positive direction for the Free Software movement. However, this would require a large break from the mainstream thought of how software should be created.

15 Jul 2003 (updated 15 Jul 2003 at 21:41 UTC) »
freetype, If my last post seemed to you an emotional reaction to "anti-aliased" fonts, my apology. I have nothing against this technology.

I think we agree it is a matter of aesthetics. I add in case of the implied context (application fonts), that is vanity since it apears there is much investment in the technology for little or no added benefit. Arbitrary scale, for instance, is not needed for general display of information. The only place I've seen it needed is desktop publishing. Desktop publishing can be considered a specical case, and characters for the most part can be treated like any other shape.

Aesthetically I find current user interfaces repulsive. Gnome, KDE, OS X, Windows XP have all taken the same path. Lots of what is called "eye candy" (vanity), little of any actual thought is put into these interfaces. It is not too different from the latest blockbuster movies when you think about it. Perhaps this is something that is intrinsic in our present culture. In any event I'd like to show that a different way is possible.

53 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!