June 22, 2003

FOAF 4 IndyMedia

IndyMedia is a project well worth supporting. The mainstream media industry is great and all, but after a while, it gets boring being lied to. IndyMedia is a brave effort towards a more inclusive approach to media access, although currently it lacks much by way of trust and 'provenance' infrastructure. Slashdot, the geek news site, has more filtering and trust machinery than most current IndyMedia sites. IndyMedia risks being drowned out by noise and spam...

So I've been experimenting with a proposal for FOAF augmented RSS feeds in the Mir content management system which now powers the UK IMC. It raises issues about privacy, identity, and (most immediately) technical concerns about the proper use of 'dc:creator' in RSS 1.0 feeds.This is a modest step towards some machinery for filtering IndyMedia news through 'web of trust' machinery. Not censorship, just a way of keeping track of who said what, and what other things those sayers have said...

Posted by danbri at June 22, 2003 01:00 AM | TrackBack
Comments

These secret identities serve a variety of purposes, and they help us to understand how variables work. In this lesson, we'll be writing a little less code than we've done in previous articles, but we'll be taking a detailed look at how variables live and work.

Posted by: Emmett on January 20, 2004 07:52 AM

The Stack is just what it sounds like: a tower of things that starts at the bottom and builds upward as it goes. In our case, the things in the stack are called "Stack Frames" or just "frames". We start with one stack frame at the very bottom, and we build up from there.

Posted by: Ciriacus on January 20, 2004 07:53 AM

The Stack is just what it sounds like: a tower of things that starts at the bottom and builds upward as it goes. In our case, the things in the stack are called "Stack Frames" or just "frames". We start with one stack frame at the very bottom, and we build up from there.

Posted by: Leonard on January 20, 2004 07:53 AM

This will allow us to use a few functions we didn't have access to before. These lines are still a mystery for now, but we'll explain them soon. Now we'll start working within the main function, where favoriteNumber is declared and used. The first thing we need to do is change how we declare the variable. Instead of

Posted by: Melchior on January 20, 2004 07:53 AM

Inside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.

Posted by: Bennett on January 20, 2004 07:53 AM

This back and forth is an important concept to understand in C programming, especially on the Mac's RISC architecture. Almost every variable you work with can be represented in 32 bits of memory: thirty-two 1s and 0s define the data that a simple variable can hold. There are exceptions, like on the new 64-bit G5s and in the 128-bit world of AltiVec

Posted by: Constance on January 20, 2004 07:53 AM

When the machine compiles your code, however, it does a little bit of translation. At run time, the computer sees nothing but 1s and 0s, which is all the computer ever sees: a continuous string of binary numbers that it can interpret in various ways.

Posted by: Arthur on January 20, 2004 07:54 AM

Let's see an example by converting our favoriteNumber variable from a stack variable to a heap variable. The first thing we'll do is find the project we've been working on and open it up in Project Builder. In the file, we'll start right at the top and work our way down. Under the line:

Posted by: Ellois on January 20, 2004 07:54 AM

This is another function provided for dealing with the heap. After you've created some space in the Heap, it's yours until you let go of it. When your program is done using it, you have to explicitly tell the computer that you don't need it anymore or the computer will save it for your future use (or until your program quits, when it knows you won't be needing the memory anymore). The call to simply tells the computer that you had this space, but you're done and the memory can be freed for use by something else later on.

Posted by: Polidore on January 20, 2004 07:54 AM

Since the Heap has no definite rules as to where it will create space for you, there must be some way of figuring out where your new space is. And the answer is, simply enough, addressing. When you create new space in the heap to hold your data, you get back an address that tells you where your new space is, so your bits can move in. This address is called a Pointer, and it's really just a hexadecimal number that points to a location in the heap. Since it's really just a number, it can be stored quite nicely into a variable.

Posted by: Marmaduke on January 20, 2004 07:54 AM
Post a comment