If a Slashdot reader can create a pithy and short explanation for how and why a computer program is expressive speech and/or what it expresses, it might be useful.
I wrote such a comment in a thread on Kuro5hin. The article was entitled Programming is not Art. Here was my response to that article in the same thread. If you can classify programming as artistic(as I believe it to be), then it certainly falls under the free expression category. Programming expresses ideas and thoughts in a dynamic sense, not statically like mathematics or paintings. That's what I find so great about it.
If a Slashdot reader can create a pithy and short explanation for how and why a computer program is expressive speech and/or what it expresses, it might be useful.
I wrote such a comment in a thread on Kuro5hin. The article was entitled Programming is not Art. Here was my response to that article in the same thread. If you can classify programming as artistic(as I believe it to be), then it certainly falls under the free expression category. Programming expresses ideas and thoughts in a dynamic sense, not statically like mathematics or paintings. That's what I find so great about it.
Honestly, if I had made a mistake and used virii when the correct usage is viruses, then I wouldn't mind being corrected. I want to know correct pronunciations, definitions, etc. However, the reason I used u-kernel and not -kernel or microkernel for most of my post, was simple:
, usage: µ = 7 characters
micro, usage: micro = 5 characters
u, usage: u = 1 character
I knew I was writing a long post and I that I would be using the term alot. In the interest of time I used the shortest version available and which wouldn't cause confusion. I believe it was quite clear that I was using u-kernel as a short hand for microkernel and 'u' is quite close looking to ''(missing all of 5 pixels). People don't use 'virii' as a short hand for viruses, they use virii because they don't know any better. That's a blatant mistake. I don't think I conveyed that image.
Completely incorrect. L4 is the successor to L3. Perhaps they had started with Mach, but that's because most academia research revolves around Mach(for some only-God-knows reason). Please see this post for more information and links to back this up.
Thst's all fine and good, but until I get free guitar strings, cables, and tubes for every song I write, I'll keep trying to make a living from it.
Allow me to make a substitution. "until I get free computers, cables, and monitors for every Free program I write, I'll keep trying to make a living from it." Now just like Free Software isn't for every programmer, so the Open Music License isn't for every artist. It's your music, do what you like with it. I am of the opinion that there is always a way, if you really want something. So despite the apparent difficulties you seem to forsee with the distribution of rock, it can be done.
You really shouldn't substitute a u for a mu. If you're so special that writing microkernel is too hard for you, then perhaps you should at least use the right symbol. A (mu) is not the same as a u.
Thank you very much for reducing my informed, intelligent and helpful post(which I took quite a bit of time out of my day to write simply because I wanted to help someone out), to piece of shit by a completely petty and stupid nitpick. No, I really appreciate it.Thank you. Perhaps you should try adding to the discussion next time, instead of bitching about something completely unimportant. If you're constipated(as seems to be the case), might I suggest adding more fiber to your diet.
When was the last time you heard real techno on the radio? The radio stations that people actually listen to play either oldies (aka "trademark music") or rock.
I live in Toronto, Canada, and "techno"(in your sense) is very popular here. I meant to say that I create this music, not that I just listen to it.
MIDI (at least General MIDI 1) is very orchestral-biased. Sure you can release your techno as.xm/.s3m/.it, but not everybody likes techno.
You're misunderstanding. I don't use MIDI for listening to the music; I use MIDI to control my external sound hardware(which is what it's designed to do). If you have an electronic keyboard(or sound card with built-in sounds), and you download a MIDI file you can assign any instrument to play the pattern coded in the file. So if you wanted to disseminate a drum pattern, or piano melody, all you need to give is the pattern and you can play with it however you like.
Except that in the case of rock music, external hardware to produce a recording from the composition involves wetware (humans to sing and humans to play guitars), and use of wetware is billed by the hour (minimum wage laws).
Yeah, so? If you want to create a remix of a song-and do a good job-you need to spend time and money. The music would still be provided in finished form(ie. mp3) for listening, but if you want to create your own mix, or version, you could just download the patterns as MIDI files(for electronic music anyway). Perhaps you misunderstood what I meant?
I'll speak from what experience I have: electronic music. I'm sure you know of MIDI files. Patterns and melodies can be taken from those as the sounds themselves are provided by external hardware. If other people want to use the patterns, they can provide their own sounds, instruments, or whatever else may be needed. You're not in this to baby them, you're in this to satisfy yourself and distribute your music. There's no clause in the license requiring you to ensure the people who download your music can start up there own studio and make their own songs. That's their responsibility.
If you wanted to provide your recorded tracks then by all means do. There are Free lossless compression algorithms that will take AudioCD and reduce the size by a good 20-30%. Since most songs are composed of individually recorded audio tracks and these tracks are stored on HD's then mixed down to DAT's, ADAT's or CD's (once again, the way I do it), then you could just post your tracks. Once again, if you wanted to.
As far as inspiration goes, I can make music today that is inspired by other music without copyright worries. (Using the lyrics and musical arrangement does create problems though).
Inspired, yes. Derived, no. And reusing lyrics and arrangments is the whole point I was trying to make. What if you want one little thing changed in an otherwise perfect song. You can do it if you really wanted to. Before you were just stuck with it.
The problem with music is that it's not code. Code is functional. It is useful to get a job done. Music is ( art | entertainment ), and does not serve a functional purpose.
I think you're missing the point too. I acknowledge the fact that code is different. I explicitly said that the purpose of writing a program was to use it for something. Then I said, the purpose of music is to enjoy it, or to be entertained to use your terms. Exactly where are you disagreeing with me? Perhaps if you re-read my post you'll understand. This Open Music license isn't to facilitate sharing of mixes or tracks, it's to facilitate the enjoyment of music whatever way you like to enjoy it, whether by creating it, or just listening.
BTW> I was thinking. From looking at the Win95 design, it seems to me that Win95 may just be the most "advanced" of any commerical OS design. Since most Windows95 components are user-level libraries mapped into each program's address space, it would seem that Win95 is the original exokernel!
*BARF* *wipes off chin* Sorry, I couldn't help myself. I don't know enough about Win 95 architecture to comment, but it's certainly not stable or fast enough to be any kind of good design. And certainly, not even CLOSE to exokernel.
Will someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea? What is done wrong in Mach, and can it be fixed?
I don't know enough of the Mach internals to know exactly why it's such a poor performer, but I have read alot of theories put forth. The most common(and accepted) reason is that Mach's memory management is too abstract and that because Mach is built on a hardware abstraction layer. Those two reasons are directly interrelated.
The Hardware abstraction layer(HAL) restricts the u-kernel to operation on a "generic machine". Everything is abstracted in the sense that the HAL contains the units which are common to all CPU architectures. This was done to improve portability. However, it sacrifices a great deal of performance because alot of issues are platform dependent. Things such as page size must be dictated by the architecture you are running on. But because Mach uses the HAL to abstract this away, Mach performance suffers a great deal in memory operations. Often, the HAL dictates a page size which is too small/large for the architecture. The hardware can't handle address translation anymore, so the kernel has to do this manually. This is very expensive.
In general, Mach's architecture just seems poorly designed from what I've read. Alot of research has been done on this topic, and they're coming to the realization that u-kernels are inherently non-portable. That's a very important point. This shouldn't be surprising either because the u-kernel is so small that mostly only platform dependent code end up in there. L4 is 12k, Eros is 32k(I think), VSTa is around 50k and QNX is less than 10k!
The good thing about this approach is that most(if not all) of the platform-dependent code is wrapped up in the u-kernel. The rest of the system is completely portable. So all you have to do is re-write about half of a 20k kernel for the new architecture, and you're done! Re-compile and off you go. Theoretically at least.;-)
If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel? Are any well-designed microkernels out there?
Good u-kernels that have implementations with performance comparable to or exceeding Linux:
QNX: Everyone's heard of this one. They have a very good u-kernel.
Opearting Systems Group at Dresden: They do alot of great work with u-kernels. They have code for L3 and L4, the first very promising, high-performance u-kernels(though they may not have designed them). They even have Linux running as a service on top of L4, so you may be able to run it right now! Also see This University and the L4KA page for other implementations of L4(ie. other architectures).
Eros: EROS is a new operating system based on the architectures of earlier high-security capability systems(KeyKOS). Very promising and has performance comparable to L4. The measurements are in the papers section(usually towards the end of the paper). System is GPL'd.
VSTa: a cool GPL'd hobby u-kernel system(in that it has no university or company backing). This one has a somewhat complete system, ie. self-hosted with gcc, vi, emacs, etc. Runs on a windows partition and uses GRUB to boot(all of which you'll need to run it). No performance metrics that I'm aware of.
Fluke: No working system as far as I know. The kernel is complete and some performance measurements have been made. Looks promising and source is available(GPL I think).
Helpful note: if I've listed a website to a university site or academic operating system/kernel, the documentation easiest to skim is found in the papers they've published.
If there are, then what is it that repeatedly leads projects like xMach/HURD/OS X/mkLinux to embrace Mach as opposed to one of the competing microkernels?
I have no idea. Ignorance of their existence probably.
Unless i am quite confused, supposedly, because the interaction between the microkernel and the OS is somewhat abstract, you ought to be able to replace the microkernel with a better one as long as the interface is the same. Is there any reason a better microkernel with the same software-side interface as Mach could not be written, and used to replace mach?
Yes you could. But then you'd just have Mach.:-) You might be able to engineer the Mach implementation a little better, but having the same interface for the most part means making the same tradeoffs, and then all you'll have left is a bastard child of Mach. *shudder*;-)
someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true? How does that work in terms of sharing the hardware? How do you go about doing this?
Yes that's true, but not in the way you're thinking. Both kernels don't run as kernels at the same time. A well-engineered u-kernel is so thin and provides such a minimal interface to the hardware, that by just slightly modifying Linux(or other kernel) you can get it to run on top of the u-kernel like any other application, and it could do everything that Linux does running on the bare hardware. See L4Linux, MkLinux, Darwin/MacOS X and even this xMach project as examples. The key to good performance is to provide as small a u-kernel with as minimal an interface as feasible to avoid performance problems. It will never run as fast as on bare hardware, but you can get pretty damn close.
I am just thinking that at this point, it would be an utterly useless but nifty parlor trick to try to get Mac OS X/Darwin, MkLinux, xMach and HURD running off the same mach microkernel on the same machine at the same time.
Not so useless as you might think. The problem with any new operating system or kernel is software. There's nothing written for it yet. But what if you could run the Linux kernel on top of your new OS? You'd have near instant access to whatever drivers and applications are currently available for Linux without any porting effort! (except for the initial Linux port) Then you can have a complete system and start writing native drivers for what you need.
However there are more useful things. Maybe a nice Wagner opera or something but usually it's just cold miserable calculation and grief.
Until your program works! Then it's a symphony! Every time it runs it's like beautiful music! da dum, dum, dum... Until it crashes. Then it's like an atomic bomb and you can feel the shock waves destroying all your hope and incinerating the orchestra playing that beautiful music. "No! I fixed it! I thought I was done!" while the midnight deadline for that assignment approaches... Programming is like music and war. Cold calculation and grief my ass!
I don't see a direct benefit to the original artist from derived works.
I think you guys are missing the point. The benefit of writing Free Software is being able to actually use it and have it used and not sacrifice liberties and freedoms. Improvements via patches are only to improve the software in some way. Music is the same in that the purpose of music is to enjoy it. It elicits strong feelings and emotions(NOTE: if your music doesn't do this for you, look for better music;-). But submitting changes and having them integrated into a song like the software model is just ridiculous. Music is a creative endeavour pursued by people/person with a vision.
The purpose of allowing modifications and derived works is to permit the creation of new songs based on inspirational ideas found in other songs. Some people may not like the guitar or the arrangment you used and so create a new mix. Different versions will appeal to different people. You might even like the remixes of your song in that they may provide a completely different and refreshing feel to something you created, so they would benefit you as well. The point of Open Music is maximizing enjoyment for everyone, including the artists(who can draw inspiration and ideas without legal worries), just like Free Software is about maximizing the usefulness of software while not compromising your freedom to do what you want with it. THAT's the point.
It could be argued that the former is easier to read, since it is cleaner.
Cleaner does not always mean clearer. I don't find your way clearer at all. Let's propose a hypothetical(yet common) situation. C requires you to declare all variable at the beginning of any block. You declare an 'int *p;' at the start of your function. About twenty or so lines down, you're tracing through some deeply nested some 'if' statement or some loop. In an average program, you'd normally have quite a few things to keep an eye on. You may have some structures with their own members being read, swapped, deleted, looping variables, etc., then all of a sudden you come across the following line:
p = malloc(sizeof(int));
Since C is so versatile(sometimes painfully so), I can only hope but wonder at what the person who wrote the code intended. What is p? I'd have to go back up to the declaration to make sure it's an (int *) and make sure it is what I think it is, and not some other funky magic the programmer was attempting.
Proper casting encourages good style and (more) correct programming because it forces you to think about what you're doing instead of blindly throwing pointers around(which, if you've ever done any C programming, you know is an easy trap to fall into). Seeing code that casts everything properly shows me that the person put a little more thought into their code. I'd more readily trust that kind of code.
I'm not suggesting it happens often. I was just pointing out a potential drawback to casting the return value of malloc, in addition to the fact that it accomplishes nothing.
I know you were trying to say it was a drawback. In my opinion, you're example was pointless. It's like saying you need the proper sequence of steps to start a car, and if you don't follow them the car won't start. That's just the way the world works, and you won't find anything that doesn't have it's tradeoffs and drawbacks. Your example was just a nitpick.
The standard says that the casts are unneccessary.
If the standard said that casts were unnecessary, there would be no built-in type checking in compilers. Also, it would be impossible to convert between types such as int(32-bit in GCC) and chars(8 bit). Alot of common code would be completely invalidated without casting. In short, no, casting is quite necessary.
If you have included stdlib.h, this code is correct, with or without the cast.
No, it's not correct(in that it won't do what you expect it do), but it is valid code.
Btw, I just looked in my copy of K&R2 and noticed that they cast the return value of malloc. Their influence over what is considered good C style is (rightfully, IMO) powerful. Then again, K&R also allow their hello world program to fall out of main() without returning a value...
Since you have the K&R2 book, perhaps you should check out page 142, near the bottom(just before that code snippet), quoted here for convenience:
The question of the type declaration for a function like malloc is a vexing one for any language that takes type-checking seriously. In C, the proper method is to declare that malloc returns a pointer to void, then explicitly coerce the pointer into the desired type with a cast.
The only reason that you can use the allocated memory without casting is because compilers cast it for you. Unfortunately, this leads people to believe that you don't have to cast things since they believe the compiler will handle it for them. But like I've said before, the compiler will not always be right in guessing what you meant and then you'll just be left scratching your head wondering what's wrong.
As for the hello world program, it seems they only do it for the first chapter. I'm sure they were just trying to concentrate on getting some key points across and not have to explain every niddling little detail to a beginner.
Huh? As I read it, the original line is quite correct: malloc a chunk the size of an int, treat the return pointer as a pointer to int, and store that pointer as 'pi.'
*sigh* I'm studying for exams, and my brain hurts. Forgive my mistake. You and I(in my original post) are correct...
In ANSI C you are always allowed to assign void* to another pointer type. In fact, that is what void* is for. Adding a cast buys nothing.
Adding a cast provides consistency, clarity, good style and correctness. The compiler may not care, but it will sometimes misinterpret what you mean, and your programming colleagues will thank you for being clear in your code.
Moreover, adding a cast can disguise the fact that you've forgotten to #include stdlib.h. If you forget to include this header (which has the prototype for malloc), then the compiler will assume that malloc returns an int.
How often does that happen? You're telling me that I should always program in bad style for the odd time I might forget to include stdlib.h? I've forgotten to do it before, and that kind of mistake is always immediately obvious. And if you do it often enough for it to be a major problem, I suggest actually paying attention to what you're doing. I'm not flaming here, but honestly, that's like forgetting how to add 5 and 6. There might be the odd time you get it wrong, but it only takes a moment to realize your mistake. If you're consistently adding 5 and 6 wrong, then you might want to go back to grade 2.
Normally, this would fail to compile when you try to assign it to a pointer. But if you have included the cast, your program will compile and silently mix integers and pointers. This will work on a machine where pointers really do have the same physical representation as ints, but will fail elsewhere. Thus, not only is the cast not needed, it actually makes your program more prone to portability bugs.
I think that saying 'programming according to the language standard reduces portability' is a ridiculous statement. But I just noticed a possible source of misunderstanding between us. It's in the line:
int* pi = (int*)malloc(sizeof(int));
Which I said was correct. It is NOT correct even with the cast. It's valid, but not correct. That statement is requesting an int and assigning it to a pointer. That should read:
int* pi = (int*)malloc(sizeof(int *)); or
int pi = (int)malloc(sizeof(int));
Which ever he meant. Those are correct statements. The first was an oversight on my part. Perhaps that's what you meant about decreasing portability due to differing implementations of (void *) and int? (in which case I would agree with you because it's bad programming)
The fact that the previous, incorrect statement would be legal in C++ worries me even more. Perhaps the original poster mistyped?
int* pi = malloc(sizeof(int));
That's an illegal C++ statement!
It's technically not legal in C either, but compilers accept it since they assume they know what the programmer meant.
int* pi = (int*)malloc(sizeof(int));
Now, that C++-version is legal C, but it is *poorly written* C code. Any C programmer worth his salt would frown on a program littered with such statements.
What are you talking about? That's perfect code. You should always cast your return values to the approriate type. It enforces type checking. Doing otherwise can be dangerous. Anyone not doing it should be immediately shot. Perhaps you should check out the Ten Commandments for C Programmers. Specifically, commandment 3 and 4. Malloc is a library function which returns a (void *). That is an illegal pointer to dereference, modify or use in any meaningful way. You have to cast it to use it.
Most modern compilers often just do it for you, but assuming a compiler will do it for you reduces portability. Also, subtle bugs can appear since the compiler has to interpret what you meant. This case is pretty clear what the intention is, but more complicates situations are sure to come up where the compiler will guess wrong and you'll be sitting there scratching your head wondering why your program is segfaulting.
Excellent point, and one that isn't widely known and cannot be stressed enough. It essentially comes down to this: we're drugging kids because they're not behaving the way we want them to. Does that sound right to you?
As someone else mentioned, Gigabit ethernet cards almost max out the PCI bus already. If you want 2 cards, well you're shit out of luck. Unless you have 2 PCI busses...
Slashdot Mirror
If a Slashdot reader can create a pithy and short explanation for how and why a computer program is expressive speech and/or what it expresses, it might be useful.
I wrote such a comment in a thread on Kuro5hin. The article was entitled Programming is not Art. Here was my response to that article in the same thread. If you can classify programming as artistic(as I believe it to be), then it certainly falls under the free expression category. Programming expresses ideas and thoughts in a dynamic sense, not statically like mathematics or paintings. That's what I find so great about it.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
If a Slashdot reader can create a pithy and short explanation for how and why a computer program is expressive speech and/or what it expresses, it might be useful.
I wrote such a comment in a thread on Kuro5hin. The article was entitled Programming is not Art. Here was my response to that article in the same thread. If you can classify programming as artistic(as I believe it to be), then it certainly falls under the free expression category. Programming expresses ideas and thoughts in a dynamic sense, not statically like mathematics or paintings. That's what I find so great about it.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
I thought this quote read:
-----
"Goose... Geese... Moose... MOOSE!?!?!"
If a user-level application can bring down the operating system, then that is a bug in the operating system.
;-)
No, it's called Windows(and MacOS for that matter).
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Real & MS & QT give away the client, then charge big $$ for encoding/server software
Darwin Streaming Server available for download.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
- , usage: µ = 7 characters
- micro, usage: micro = 5 characters
- u, usage: u = 1 character
I knew I was writing a long post and I that I would be using the term alot. In the interest of time I used the shortest version available and which wouldn't cause confusion. I believe it was quite clear that I was using u-kernel as a short hand for microkernel and 'u' is quite close looking to ''(missing all of 5 pixels). People don't use 'virii' as a short hand for viruses, they use virii because they don't know any better. That's a blatant mistake. I don't think I conveyed that image.-----
"Goose... Geese... Moose... MOOSE!?!?!"
The L4 micro-kernel is the "successor" to Mach.
Completely incorrect. L4 is the successor to L3. Perhaps they had started with Mach, but that's because most academia research revolves around Mach(for some only-God-knows reason). Please see this post for more information and links to back this up.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Thst's all fine and good, but until I get free guitar strings, cables, and tubes for every song I write, I'll keep trying to make a living from it.
Allow me to make a substitution. "until I get free computers, cables, and monitors for every Free program I write, I'll keep trying to make a living from it." Now just like Free Software isn't for every programmer, so the Open Music License isn't for every artist. It's your music, do what you like with it. I am of the opinion that there is always a way, if you really want something. So despite the apparent difficulties you seem to forsee with the distribution of rock, it can be done.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
You really shouldn't substitute a u for a mu. If you're so special that writing microkernel is too hard for you, then perhaps you should at least use the right symbol. A (mu) is not the same as a u.
Thank you very much for reducing my informed, intelligent and helpful post(which I took quite a bit of time out of my day to write simply because I wanted to help someone out), to piece of shit by a completely petty and stupid nitpick. No, I really appreciate it.Thank you. Perhaps you should try adding to the discussion next time, instead of bitching about something completely unimportant. If you're constipated(as seems to be the case), might I suggest adding more fiber to your diet.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
On time pads are very secure and if used correctly, are very difficult to break.
:-)
No, they are, literally, mathematically IMPOSSIBLE to break. If you use them correctly, like you said.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
When was the last time you heard real techno on the radio? The radio stations that people actually listen to play either oldies (aka "trademark music") or rock.
.xm/.s3m/.it, but not everybody likes techno.
I live in Toronto, Canada, and "techno"(in your sense) is very popular here. I meant to say that I create this music, not that I just listen to it.
MIDI (at least General MIDI 1) is very orchestral-biased. Sure you can release your techno as
You're misunderstanding. I don't use MIDI for listening to the music; I use MIDI to control my external sound hardware(which is what it's designed to do). If you have an electronic keyboard(or sound card with built-in sounds), and you download a MIDI file you can assign any instrument to play the pattern coded in the file. So if you wanted to disseminate a drum pattern, or piano melody, all you need to give is the pattern and you can play with it however you like.
Except that in the case of rock music, external hardware to produce a recording from the composition involves wetware (humans to sing and humans to play guitars), and use of wetware is billed by the hour (minimum wage laws).
Yeah, so? If you want to create a remix of a song-and do a good job-you need to spend time and money. The music would still be provided in finished form(ie. mp3) for listening, but if you want to create your own mix, or version, you could just download the patterns as MIDI files(for electronic music anyway). Perhaps you misunderstood what I meant?
-----
"Goose... Geese... Moose... MOOSE!?!?!"
I'll speak from what experience I have: electronic music. I'm sure you know of MIDI files. Patterns and melodies can be taken from those as the sounds themselves are provided by external hardware. If other people want to use the patterns, they can provide their own sounds, instruments, or whatever else may be needed. You're not in this to baby them, you're in this to satisfy yourself and distribute your music. There's no clause in the license requiring you to ensure the people who download your music can start up there own studio and make their own songs. That's their responsibility.
If you wanted to provide your recorded tracks then by all means do. There are Free lossless compression algorithms that will take AudioCD and reduce the size by a good 20-30%. Since most songs are composed of individually recorded audio tracks and these tracks are stored on HD's then mixed down to DAT's, ADAT's or CD's (once again, the way I do it), then you could just post your tracks. Once again, if you wanted to.
As far as inspiration goes, I can make music today that is inspired by other music without copyright worries. (Using the lyrics and musical arrangement does create problems though).
Inspired, yes. Derived, no. And reusing lyrics and arrangments is the whole point I was trying to make. What if you want one little thing changed in an otherwise perfect song. You can do it if you really wanted to. Before you were just stuck with it.
The problem with music is that it's not code. Code is functional. It is useful to get a job done. Music is ( art | entertainment ), and does not serve a functional purpose.
I think you're missing the point too. I acknowledge the fact that code is different. I explicitly said that the purpose of writing a program was to use it for something. Then I said, the purpose of music is to enjoy it, or to be entertained to use your terms. Exactly where are you disagreeing with me? Perhaps if you re-read my post you'll understand. This Open Music license isn't to facilitate sharing of mixes or tracks, it's to facilitate the enjoyment of music whatever way you like to enjoy it, whether by creating it, or just listening.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
No, no, noooo. Read it again. He said "used successfully". And they have, haven't they? ;-)
-----
"Goose... Geese... Moose... MOOSE!?!?!"
BTW> I was thinking. From looking at the Win95 design, it seems to me that Win95 may just be the most "advanced" of any commerical OS design. Since most Windows95 components are user-level libraries mapped into each program's address space, it would seem that Win95 is the original exokernel!
*BARF* *wipes off chin* Sorry, I couldn't help myself. I don't know enough about Win 95 architecture to comment, but it's certainly not stable or fast enough to be any kind of good design. And certainly, not even CLOSE to exokernel.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
I don't know enough of the Mach internals to know exactly why it's such a poor performer, but I have read alot of theories put forth. The most common(and accepted) reason is that Mach's memory management is too abstract and that because Mach is built on a hardware abstraction layer. Those two reasons are directly interrelated.
The Hardware abstraction layer(HAL) restricts the u-kernel to operation on a "generic machine". Everything is abstracted in the sense that the HAL contains the units which are common to all CPU architectures. This was done to improve portability. However, it sacrifices a great deal of performance because alot of issues are platform dependent. Things such as page size must be dictated by the architecture you are running on. But because Mach uses the HAL to abstract this away, Mach performance suffers a great deal in memory operations. Often, the HAL dictates a page size which is too small/large for the architecture. The hardware can't handle address translation anymore, so the kernel has to do this manually. This is very expensive.
In general, Mach's architecture just seems poorly designed from what I've read. Alot of research has been done on this topic, and they're coming to the realization that u-kernels are inherently non-portable. That's a very important point. This shouldn't be surprising either because the u-kernel is so small that mostly only platform dependent code end up in there. L4 is 12k, Eros is 32k(I think), VSTa is around 50k and QNX is less than 10k!
The good thing about this approach is that most(if not all) of the platform-dependent code is wrapped up in the u-kernel. The rest of the system is completely portable. So all you have to do is re-write about half of a 20k kernel for the new architecture, and you're done! Re-compile and off you go. Theoretically at least.
If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel? Are any well-designed microkernels out there?
Good u-kernels that have implementations with performance comparable to or exceeding Linux:
- QNX: Everyone's heard of this one. They have a very good u-kernel.
- Opearting Systems Group at Dresden: They do alot of great work with u-kernels. They have code for L3 and L4, the first very promising, high-performance u-kernels(though they may not have designed them). They even have Linux running as a service on top of L4, so you may be able to run it right now! Also see This University and the L4KA page for other implementations of L4(ie. other architectures).
- Eros: EROS is a new operating system based on the architectures of earlier high-security capability systems(KeyKOS). Very promising and has performance comparable to L4. The measurements are in the papers section(usually towards the end of the paper). System is GPL'd.
- VSTa: a cool GPL'd hobby u-kernel system(in that it has no university or company backing). This one has a somewhat complete system, ie. self-hosted with gcc, vi, emacs, etc. Runs on a windows partition and uses GRUB to boot(all of which you'll need to run it). No performance metrics that I'm aware of.
- Fluke: No working system as far as I know. The kernel is complete and some performance measurements have been made. Looks promising and source is available(GPL I think).
Helpful note: if I've listed a website to a university site or academic operating system/kernel, the documentation easiest to skim is found in the papers they've published.If there are, then what is it that repeatedly leads projects like xMach/HURD/OS X/mkLinux to embrace Mach as opposed to one of the competing microkernels?
I have no idea. Ignorance of their existence probably.
Unless i am quite confused, supposedly, because the interaction between the microkernel and the OS is somewhat abstract, you ought to be able to replace the microkernel with a better one as long as the interface is the same. Is there any reason a better microkernel with the same software-side interface as Mach could not be written, and used to replace mach?
Yes you could. But then you'd just have Mach.
someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true? How does that work in terms of sharing the hardware? How do you go about doing this?
Yes that's true, but not in the way you're thinking. Both kernels don't run as kernels at the same time. A well-engineered u-kernel is so thin and provides such a minimal interface to the hardware, that by just slightly modifying Linux(or other kernel) you can get it to run on top of the u-kernel like any other application, and it could do everything that Linux does running on the bare hardware. See L4Linux, MkLinux, Darwin/MacOS X and even this xMach project as examples. The key to good performance is to provide as small a u-kernel with as minimal an interface as feasible to avoid performance problems. It will never run as fast as on bare hardware, but you can get pretty damn close.
I am just thinking that at this point, it would be an utterly useless but nifty parlor trick to try to get Mac OS X/Darwin, MkLinux, xMach and HURD running off the same mach microkernel on the same machine at the same time.
Not so useless as you might think. The problem with any new operating system or kernel is software. There's nothing written for it yet. But what if you could run the Linux kernel on top of your new OS? You'd have near instant access to whatever drivers and applications are currently available for Linux without any porting effort! (except for the initial Linux port) Then you can have a complete system and start writing native drivers for what you need.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
To most people microkernel == Mach (which has never been used successfully in a production system)
NeXT, MacOS X, MacOS X server(in use for 2 years now).
-----
"Goose... Geese... Moose... MOOSE!?!?!"
However there are more useful things. Maybe a nice Wagner opera or something but usually it's just cold miserable calculation and grief.
Until your program works! Then it's a symphony! Every time it runs it's like beautiful music! da dum, dum, dum... Until it crashes. Then it's like an atomic bomb and you can feel the shock waves destroying all your hope and incinerating the orchestra playing that beautiful music. "No! I fixed it! I thought I was done!" while the midnight deadline for that assignment approaches... Programming is like music and war. Cold calculation and grief my ass!
-----
"Goose... Geese... Moose... MOOSE!?!?!"
I don't see a direct benefit to the original artist from derived works.
;-). But submitting changes and having them integrated into a song like the software model is just ridiculous. Music is a creative endeavour pursued by people/person with a vision.
I think you guys are missing the point. The benefit of writing Free Software is being able to actually use it and have it used and not sacrifice liberties and freedoms. Improvements via patches are only to improve the software in some way. Music is the same in that the purpose of music is to enjoy it. It elicits strong feelings and emotions(NOTE: if your music doesn't do this for you, look for better music
The purpose of allowing modifications and derived works is to permit the creation of new songs based on inspirational ideas found in other songs. Some people may not like the guitar or the arrangment you used and so create a new mix. Different versions will appeal to different people. You might even like the remixes of your song in that they may provide a completely different and refreshing feel to something you created, so they would benefit you as well. The point of Open Music is maximizing enjoyment for everyone, including the artists(who can draw inspiration and ideas without legal worries), just like Free Software is about maximizing the usefulness of software while not compromising your freedom to do what you want with it. THAT's the point.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Cleaner does not always mean clearer. I don't find your way clearer at all. Let's propose a hypothetical(yet common) situation. C requires you to declare all variable at the beginning of any block. You declare an 'int *p;' at the start of your function. About twenty or so lines down, you're tracing through some deeply nested some 'if' statement or some loop. In an average program, you'd normally have quite a few things to keep an eye on. You may have some structures with their own members being read, swapped, deleted, looping variables, etc., then all of a sudden you come across the following line:
p = malloc(sizeof(int));
Since C is so versatile(sometimes painfully so), I can only hope but wonder at what the person who wrote the code intended. What is p? I'd have to go back up to the declaration to make sure it's an (int *) and make sure it is what I think it is, and not some other funky magic the programmer was attempting.
Proper casting encourages good style and (more) correct programming because it forces you to think about what you're doing instead of blindly throwing pointers around(which, if you've ever done any C programming, you know is an easy trap to fall into). Seeing code that casts everything properly shows me that the person put a little more thought into their code. I'd more readily trust that kind of code.
I'm not suggesting it happens often. I was just pointing out a potential drawback to casting the return value of malloc, in addition to the fact that it accomplishes nothing.
I know you were trying to say it was a drawback. In my opinion, you're example was pointless. It's like saying you need the proper sequence of steps to start a car, and if you don't follow them the car won't start. That's just the way the world works, and you won't find anything that doesn't have it's tradeoffs and drawbacks. Your example was just a nitpick.
The standard says that the casts are unneccessary.
If the standard said that casts were unnecessary, there would be no built-in type checking in compilers. Also, it would be impossible to convert between types such as int(32-bit in GCC) and chars(8 bit). Alot of common code would be completely invalidated without casting. In short, no, casting is quite necessary.
If you have included stdlib.h, this code is correct, with or without the cast.
No, it's not correct(in that it won't do what you expect it do), but it is valid code.
Btw, I just looked in my copy of K&R2 and noticed that they cast the return value of malloc. Their influence over what is considered good C style is (rightfully, IMO) powerful. Then again, K&R also allow their hello world program to fall out of main() without returning a value...
Since you have the K&R2 book, perhaps you should check out page 142, near the bottom(just before that code snippet), quoted here for convenience: The only reason that you can use the allocated memory without casting is because compilers cast it for you. Unfortunately, this leads people to believe that you don't have to cast things since they believe the compiler will handle it for them. But like I've said before, the compiler will not always be right in guessing what you meant and then you'll just be left scratching your head wondering what's wrong.
As for the hello world program, it seems they only do it for the first chapter. I'm sure they were just trying to concentrate on getting some key points across and not have to explain every niddling little detail to a beginner.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Huh? As I read it, the original line is quite correct: malloc a chunk the size of an int, treat the return pointer as a pointer to int, and store that pointer as 'pi.'
*sigh* I'm studying for exams, and my brain hurts. Forgive my mistake. You and I(in my original post) are correct...
-----
"Goose... Geese... Moose... MOOSE!?!?!"
In ANSI C you are always allowed to assign void* to another pointer type. In fact, that is what void* is for. Adding a cast buys nothing.
Adding a cast provides consistency, clarity, good style and correctness. The compiler may not care, but it will sometimes misinterpret what you mean, and your programming colleagues will thank you for being clear in your code.
Moreover, adding a cast can disguise the fact that you've forgotten to #include stdlib.h. If you forget to include this header (which has the prototype for malloc), then the compiler will assume that malloc returns an int.
How often does that happen? You're telling me that I should always program in bad style for the odd time I might forget to include stdlib.h? I've forgotten to do it before, and that kind of mistake is always immediately obvious. And if you do it often enough for it to be a major problem, I suggest actually paying attention to what you're doing. I'm not flaming here, but honestly, that's like forgetting how to add 5 and 6. There might be the odd time you get it wrong, but it only takes a moment to realize your mistake. If you're consistently adding 5 and 6 wrong, then you might want to go back to grade 2.
Normally, this would fail to compile when you try to assign it to a pointer. But if you have included the cast, your program will compile and silently mix integers and pointers. This will work on a machine where pointers really do have the same physical representation as ints, but will fail elsewhere. Thus, not only is the cast not needed, it actually makes your program more prone to portability bugs.
I think that saying 'programming according to the language standard reduces portability' is a ridiculous statement. But I just noticed a possible source of misunderstanding between us. It's in the line:
int* pi = (int*)malloc(sizeof(int));
Which I said was correct. It is NOT correct even with the cast. It's valid, but not correct. That statement is requesting an int and assigning it to a pointer. That should read:
int* pi = (int*)malloc(sizeof(int *));
or
int pi = (int)malloc(sizeof(int));
Which ever he meant. Those are correct statements. The first was an oversight on my part. Perhaps that's what you meant about decreasing portability due to differing implementations of (void *) and int? (in which case I would agree with you because it's bad programming)
The fact that the previous, incorrect statement would be legal in C++ worries me even more. Perhaps the original poster mistyped?
-----
"Goose... Geese... Moose... MOOSE!?!?!"
int* pi = malloc(sizeof(int));
That's an illegal C++ statement!
It's technically not legal in C either, but compilers accept it since they assume they know what the programmer meant.
int* pi = (int*)malloc(sizeof(int));
Now, that C++-version is legal C, but it is *poorly written* C code. Any C programmer worth his salt would frown on a program littered with such statements.
What are you talking about? That's perfect code. You should always cast your return values to the approriate type. It enforces type checking. Doing otherwise can be dangerous. Anyone not doing it should be immediately shot. Perhaps you should check out the Ten Commandments for C Programmers. Specifically, commandment 3 and 4. Malloc is a library function which returns a (void *). That is an illegal pointer to dereference, modify or use in any meaningful way. You have to cast it to use it.
Most modern compilers often just do it for you, but assuming a compiler will do it for you reduces portability. Also, subtle bugs can appear since the compiler has to interpret what you meant. This case is pretty clear what the intention is, but more complicates situations are sure to come up where the compiler will guess wrong and you'll be sitting there scratching your head wondering why your program is segfaulting.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Excellent point, and one that isn't widely known and cannot be stressed enough. It essentially comes down to this: we're drugging kids because they're not behaving the way we want them to. Does that sound right to you?
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Or go for the Open Source embedded OS, eCos
-----
"Goose... Geese... Moose... MOOSE!?!?!"
As someone else mentioned, Gigabit ethernet cards almost max out the PCI bus already. If you want 2 cards, well you're shit out of luck. Unless you have 2 PCI busses...
-----
"Goose... Geese... Moose... MOOSE!?!?!"