Slashdot Mirror

Thus, a positive side-effect of such hole is that you may freely mix free and proprietary software code from a range of otherwise incompatible licenses, as long as you don't "distribute" your code outside of your world-wide association. In other words, if you're member of the WWBA (World-Wide Bugroff Association), then you can freely mix and match most free software, as if it were under the bugroff license.

-- Faré @ TUNES.org

Conclusion: the "company" (i.e. its managers) doesn't decide. The people in the company individually decide, possibly but not necessarily in mutual consent. That is freedom.

-- Faré @ TUNES.org

Are you going to invest massively in such tracks, do you think they are merely wishful thinking, are you in a wait-and-see mode, or do you just feel unconcerned? If you think such concerns, if possibly valid, are too long-term to you, what kind of financial infrastructure do you consider appropriate for research on such topics? How do you envision the relationship between free software companies and computer science research centers?

-- Faré @ TUNES.org

Are you going to invest massively in such tracks, do you think they are merely wishful thinking, are you in a wait-and-see mode, or do you just feel unconcerned? If you think such concerns, if possibly valid, are too long-term to you, what kind of financial infrastructure do you consider appropriate for research on such topics? How do you envision the relationship between free software companies and computer science research centers?

-- Faré @ TUNES.org

Are you going to invest massively in such tracks, do you think they are merely wishful thinking, are you in a wait-and-see mode, or do you just feel unconcerned? If you think such concerns, if possibly valid, are too long-term to you, what kind of financial infrastructure do you consider appropriate for research on such topics? How do you envision the relationship between free software companies and computer science research centers?

-- Faré @ TUNES.org

Good point. Moreover, as I pointed out, the monolithic kernel vs microkernel debate is exactly a library vs client/server system, at a sufficiently abstract level.

Clearly there is nothing you can do with a library that you can't do with a client/server system. But in fact, the converse is also mostly true. It would be quite possible, IMHO, to have the Hurd features on a monolithic kernel system: essentially, the monolithic kernel provides the capacity-based security model, and the filesystems are integrated in a set of dynamic libraries rather than in a set of servers. This requires the concept of setuid (or rather, ``acquire capability'') libraries, but there is nothing fundamentally impossible with this.

So, the microkernel issue should not be judged as providing the Hurd functionality but rather, on its own grounds (replacing a library-alike calling system by a client/server model). I am not competent to judge in this matter, but one thing is certain, namely that the entire issue is not completely clear-cut. The official ``Tunes'' rant on the microkernel issue might not be completely wrong (despite the author's numerous deliberately provotating statements).

Rafael Kaufmann's parents are proud to announce his IPO, to take place in early 2000. Kaufmann has already secured the Nasdaq ticker KMNN, and is in the process of preparing for the offering by fasting (sometimes for periods of over 6 hours!) and cleaning up his place.

Kaufmann is a small individual operating out of Rio de Janeiro, Brazil, associated with the Institute for Pure and Applied Mathematics. He operates mainly in the area of computational mathematics, as well as alternative software in general. He is affiliated with the Tunes project, but has yet to do anything important.

Kaufmann's mother Drorit had no comment, but his father was quoted as saying "that boy will never amount to anything!".

Because it has already done about a dozen times (probably attempted more than 1000 times). Check the 'OS' links from www.tunes.org. There is an abondance of toy-OSes.

Perhaps some of you 1337 c0d3rZ would enjoy writing some fast clean programs, instead of the library loving crap that is *nix software these days.

Huh? I strongly doubt for instance that their filesystem is as fast as Linux's one (included in a PhD thesis), or and has a many features as the WindowsNT / Irix one (includind logging). Writing fast but retarded programs is not the way to go, unless you have fucking damn huge reasons to do so.

It was fun to write, it was a great achievement, but it is not very useful. I would have been more impressed if they had writen an Intercal compiler in x86 assembly.

The bottom line is that: the OS is the set of behaviors, whatever it be, that anyone can expect from any computer in a given set. Technical considerations of separation into kernel and applications and drivers and daemons and whatever are mostly irrelevant here. They are relevant to internal design of an OS, not to the definition of an OS as a class of externally observable phenomena (unless of course you believe that OSes are only observable by people keen in their internal design).

As progress comes (and goes), the operating system has included an increasing (and sometimes decreasing) amount of features, and been designed in more and more complex ways. From the times of hand-switching programs into memory, to interactive monitors, to batch processors, to time-sharing systems, to virtual machine systems (even recursive virtual machines on some mainframes), there has been a lot of change in OS structure. As for features, structured persistent storage (filesystems) were sure not part of early system monitors; "disk"-managing operating systems were such an exception for micro-computers that they had to be explicitly named so in the early eighties (anyone remember Apple DOS 3.3? MS-DOS 2.x?). Today, it's taken for granted. Same goes for multiprogramming, for virtual memory, for (yuck) integrated bitmapped GUI, for TCP/IP networking, for package management, computer clustering, high-availability, device pluggability, autoconfigured wireless connectivity, palm computing, home-appliance connectivity, speech control, orthogonal persistence, process migration, automatic binary/source/specification consistency management, integrated metaprogramming, etc.

Feature- and design- based characterizations of the concept of an OS are doomed, because they are inherently short-sighted. Which is precisely what allows features to characterize specific instances of "OS" by their feature: any number can play, hence a fruitful competition (well, in absence of protection barriers such as so-called intellectual property, and of technological barriers they induce such as standardization on low-level languages like C).

-- Faré @ TUNES.org

The bottom line is that: the OS is the set of behaviors, whatever it be, that anyone can expect from any computer in a given set. Technical considerations of separation into kernel and applications and drivers and daemons and whatever are mostly irrelevant here. They are relevant to internal design of an OS, not to the definition of an OS as a class of externally observable phenomena (unless of course you believe that OSes are only observable by people keen in their internal design).

As progress comes (and goes), the operating system has included an increasing (and sometimes decreasing) amount of features, and been designed in more and more complex ways. From the times of hand-switching programs into memory, to interactive monitors, to batch processors, to time-sharing systems, to virtual machine systems (even recursive virtual machines on some mainframes), there has been a lot of change in OS structure. As for features, structured persistent storage (filesystems) were sure not part of early system monitors; "disk"-managing operating systems were such an exception for micro-computers that they had to be explicitly named so in the early eighties (anyone remember Apple DOS 3.3? MS-DOS 2.x?). Today, it's taken for granted. Same goes for multiprogramming, for virtual memory, for (yuck) integrated bitmapped GUI, for TCP/IP networking, for package management, computer clustering, high-availability, device pluggability, autoconfigured wireless connectivity, palm computing, home-appliance connectivity, speech control, orthogonal persistence, process migration, automatic binary/source/specification consistency management, integrated metaprogramming, etc.

Feature- and design- based characterizations of the concept of an OS are doomed, because they are inherently short-sighted. Which is precisely what allows features to characterize specific instances of "OS" by their feature: any number can play, hence a fruitful competition (well, in absence of protection barriers such as so-called intellectual property, and of technological barriers they induce such as standardization on low-level languages like C).

-- Faré @ TUNES.org

The bottom line is that: the OS is the set of behaviors, whatever it be, that anyone can expect from any computer in a given set. Technical considerations of separation into kernel and applications and drivers and daemons and whatever are mostly irrelevant here. They are relevant to internal design of an OS, not to the definition of an OS as a class of externally observable phenomena (unless of course you believe that OSes are only observable by people keen in their internal design).

As progress comes (and goes), the operating system has included an increasing (and sometimes decreasing) amount of features, and been designed in more and more complex ways. From the times of hand-switching programs into memory, to interactive monitors, to batch processors, to time-sharing systems, to virtual machine systems (even recursive virtual machines on some mainframes), there has been a lot of change in OS structure. As for features, structured persistent storage (filesystems) were sure not part of early system monitors; "disk"-managing operating systems were such an exception for micro-computers that they had to be explicitly named so in the early eighties (anyone remember Apple DOS 3.3? MS-DOS 2.x?). Today, it's taken for granted. Same goes for multiprogramming, for virtual memory, for (yuck) integrated bitmapped GUI, for TCP/IP networking, for package management, computer clustering, high-availability, device pluggability, autoconfigured wireless connectivity, palm computing, home-appliance connectivity, speech control, orthogonal persistence, process migration, automatic binary/source/specification consistency management, integrated metaprogramming, etc.

Feature- and design- based characterizations of the concept of an OS are doomed, because they are inherently short-sighted. Which is precisely what allows features to characterize specific instances of "OS" by their feature: any number can play, hence a fruitful competition (well, in absence of protection barriers such as so-called intellectual property, and of technological barriers they induce such as standardization on low-level languages like C).

-- Faré @ TUNES.org

The bottom line is that: the OS is the set of behaviors, whatever it be, that anyone can expect from any computer in a given set. Technical considerations of separation into kernel and applications and drivers and daemons and whatever are mostly irrelevant here. They are relevant to internal design of an OS, not to the definition of an OS as a class of externally observable phenomena (unless of course you believe that OSes are only observable by people keen in their internal design).

As progress comes (and goes), the operating system has included an increasing (and sometimes decreasing) amount of features, and been designed in more and more complex ways. From the times of hand-switching programs into memory, to interactive monitors, to batch processors, to time-sharing systems, to virtual machine systems (even recursive virtual machines on some mainframes), there has been a lot of change in OS structure. As for features, structured persistent storage (filesystems) were sure not part of early system monitors; "disk"-managing operating systems were such an exception for micro-computers that they had to be explicitly named so in the early eighties (anyone remember Apple DOS 3.3? MS-DOS 2.x?). Today, it's taken for granted. Same goes for multiprogramming, for virtual memory, for (yuck) integrated bitmapped GUI, for TCP/IP networking, for package management, computer clustering, high-availability, device pluggability, autoconfigured wireless connectivity, palm computing, home-appliance connectivity, speech control, orthogonal persistence, process migration, automatic binary/source/specification consistency management, integrated metaprogramming, etc.

Feature- and design- based characterizations of the concept of an OS are doomed, because they are inherently short-sighted. Which is precisely what allows features to characterize specific instances of "OS" by their feature: any number can play, hence a fruitful competition (well, in absence of protection barriers such as so-called intellectual property, and of technological barriers they induce such as standardization on low-level languages like C).

-- Faré @ TUNES.org

Most of the other things people are doing are boring at best. SMP? Anything but new -- so you stick a few more processors in a box. Security? Capabilities are definately the right way to do stuff (EROS uses them), but they don't change computers that much. They just fine tune and generalize security, and would allow information to be more easily shared -- plus getting rid of all the dumb sandbox efforts -- but they wouldn't change what computing meant.

Microkernels were only really important on the implementation side, even if they were to have succeded. Distributed computing is still a long way off in any meaningful manner -- resource farms aren't too interesting. I can't think of much really exciting... maybe OO, CORBA, and the like have some interesting possibilities in extending the basic infrastructure on a computer.

Orthogonal persistance doesn't seem all that interesting -- persistance already exists, after all, but you just have to explicitly save (in an app), or open a file (from code). But when persistance comes for free everything is just so much easier -- and making it easier to program stuff really is important. Objects become something tangible, not attached to a process or a session. If you added OS-level garbage collection then you'd have something really powerful. Objects would finally subsume processes and algorithms and the computer would be an environment instead of a machine.

My head is in the clouds at the moment, excuse me. Anyway, if you feel like reading other clouded thoughts on OS design (none of it by me), you might be interested in the all-talk TUNES OS. Less code makes room for more talk! But you got to give them credit, at least they don't pretend to be anything but what they are :)

• the first one, that infringes the patent, is available on my page below, and should be as widely spread as possible: It's just aone transparent pixel compressed with LZW. This protest is like Mahatma Gandhi's March to the sea: Gandhi crossed half of India afoot to cristallize a single pinch of salt from the sea with a spoon, as a protest against the british monopoly on salt. He was thrown in jail, but no one would respect the monopoly anymore afterwards.
• the second one should be spread in a similar way, but it ought to be created first. Explanations given in this message

-- Faré @ TUNES.org

• the first one, that infringes the patent, is available on my page below, and should be as widely spread as possible: It's just aone transparent pixel compressed with LZW. This protest is like Mahatma Gandhi's March to the sea: Gandhi crossed half of India afoot to cristallize a single pinch of salt from the sea with a spoon, as a protest against the british monopoly on salt. He was thrown in jail, but no one would respect the monopoly anymore afterwards.
• the second one should be spread in a similar way, but it ought to be created first. Explanations given in this message

-- Faré @ TUNES.org

• the first one, that infringes the patent, is available on my page below, and should be as widely spread as possible: It's just aone transparent pixel compressed with LZW. This protest is like Mahatma Gandhi's March to the sea: Gandhi crossed half of India afoot to cristallize a single pinch of salt from the sea with a spoon, as a protest against the british monopoly on salt. He was thrown in jail, but no one would respect the monopoly anymore afterwards.
• the second one should be spread in a similar way, but it ought to be created first. Explanations given in this message

-- Faré @ TUNES.org

I'll add two suggestions to those already given:

• Tunes is an attempt to build an advanced OS around proof of correctness and other such concepts. They have a nice review of other OSes and languages, so their site is worth visiting just for that.
• Merlin is my own project for a reflective, object-oriented systems (I now call it Self/R, but this web page is a bit outdated...).

-- Jecel

-- Faré @ TUNES.org

-- Faré @ TUNES.org

I had begun an article on pretty much the same subject, and even submitted a feature proposal to Rob (that got ignored as usual). I talked about it to as much people as I could at the Free Software conference Autour du Libre 1999 in Brest this january (where I presented a paper on another topic - shameless plug), but was greeted more with polite interest than with enthusiasm.

You can read my ramblings in the draft article:
A Free Software Auction Service...

Note: as of why we mustn't fear corruption or other inefficiencies: since there is free competition among such services, that draw their money from voluntary funding, if one service is inefficient, funds will move to another one!

-- Faré@TUNES.org

I had begun an article on pretty much the same subject, and even submitted a feature proposal to Rob (that got ignored as usual). I talked about it to as much people as I could at the Free Software conference Autour du Libre 1999 in Brest this january (where I presented a paper on another topic - shameless plug), but was greeted more with polite interest than with enthusiasm.

You can read my ramblings in the draft article:
A Free Software Auction Service...

Note: as of why we mustn't fear corruption or other inefficiencies: since there is free competition among such services, that draw their money from voluntary funding, if one service is inefficient, funds will move to another one!

-- Faré@TUNES.org

I had begun an article on pretty much the same subject, and even submitted a feature proposal to Rob (that got ignored as usual). I talked about it to as much people as I could at the Free Software conference Autour du Libre 1999 in Brest this january (where I presented a paper on another topic - shameless plug), but was greeted more with polite interest than with enthusiasm.

You can read my ramblings in the draft article:
A Free Software Auction Service...

Note: as of why we mustn't fear corruption or other inefficiencies: since there is free competition among such services, that draw their money from voluntary funding, if one service is inefficient, funds will move to another one!

-- Faré@TUNES.org