Older blog entries for mslicker (starting at number 64)

It seems many acomplished free software developers aquire a certain type of pescky self-important user who only wants to complain and spread misinformation, it seems I have aquired one as well.

Don't make the mistake the offending or insulting this type of user, that only seems to make them more determined. Ignoring this type of user might be the best policy, but it might to late for that in my case.


I created a screen font, as an experiment. It is not that interesting, but it seems relatively consistent, and it fits the pixel grid well, perhaps too small for common use. It seem screen fonts are not that popular, X windows uses scalable fonts, and mozilla went to softened scaled fonts. Matthew Carter created fonts oriented to the screen by first creating optimal bitmaps and then fitting outlines to the bitmaps. For the usability people here, it might interesting to measure the readibility of different fonts on the screen.

In a web specification, I would probably only specify bitmap fonts. They are very easy to display, and don't give preference to any particular font description. How fonts are designed might evolve independently. A good compression method would be needed if bitmaps are used, this might be a canidate but I don't know of data is sparse enough. Different bitmaps could be sent depending on the device, high resolution bitmaps for a laser printer, optimized low resolution bitmaps for a typical display. The properties of the device could be sent in the request. This pushes some of the complexity of the client into the server, the server would likely cache all common requests, and likewise the client cache fonts only downloading upon need. To anticipate a likely objection, bitmaps could specify 256 levels of gray to achieve softer characters for screen display.

Characters as shapes might be best addressed seperately, rather than generalizing this with text display.

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.


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.


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.

55 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!