It's called "30 years in the real-time control systems industry".
I'm aware that a monolithic design doesn't need any kind of context separation
Neither does a microkernel design. The only microkernel designs that demand context separation are the "academic microkernels" producted by people who (I presume) looked at the way the real-time industry was doing stuff and thought "hey, that's really cool, and if we add context separation we can get something even undergrads can understand". It's no accident that the poster boys for "screwed up academic microkernels" are Mach (MIT) and Minix (VU).
network bridging kernel components [...] I can think of another technology that does this; it's called J2EE.
Also: NFS, Athena, Vice, Photon, Plan 9, half the NUMA and clustering systems in the world,...
Building an entire kernel out of little queues is just insane and infeasible in the real world.
It's a common way of building a kernel in the real world: there's probably 100 installed real-time systems for every timeshared system out there, and microkernel design is hardly unusual there.
The cost of dynamic linking is typically very small
For today's computers, yes, but you're missing the point I'm making. OK, look: [ecode] gee:/builds/glibc/cross:[254]$ LD_DEBUG=statistics elf/ld-linux.so.2 --library-path:math:linuxthreads:login:/usr/lib:/lib/opt/kde2/bin/konqueror -/ 16634: 16634: runtime linker statistics: 16634: total startup time in dynamic loader: 699430072 clock cycles 16634: time needed for relocation: 694116497 clock cycles (99.2) 16634: number of relocations: 54130 16634: time needed to load objects: 4958742 clock cycles (.7)[/ecode]Seven hundred million clock cycles in the dynamic loader starting up Konqueror, almost all relocation. Elsewhere I'm finding over a million clock cycles just for ls. Prelinking gets it down to a "mere" few hundred thousand cycles.
That's acceptable today, but back in the period I'm talking about that would be several seconds for every command. For a mainframe operating system, several seconds startup time for an execution context wasn't a big deal... typical jobs didn't create new execution contexts on a regular basis. So the mainframe guys, with this idea that creating an execution context was expensive, looked at UNIX's fork()/exec() with horror. The UNIX guys, who'd gotten rid of most of the stuff that mainframe operating systems were doing, had this big battle convincing people that the time spent reading the FORTRAN compiler's image from disk was thousands of times greater than the time spent creating its process context to run in.
Similarly, you're looking at microkernel design with this idea that message passing involves taking a message, marshalling it into a flat format, copying it, making a system call, unmarshalling it, and making a subroutine call. It's like you're a mainframe guy who thinks that creating a new process context means IPLing a new copy of CMS into a VM partition.
In a high performance microkernel message passing involves taking a message, then either (for an asynchronous queue) adding it to a linked list and then later (possibly after several messages have been queued) performing a kernel thread switch, or (for a synchronous queue) calling the handler directly. If there's a context switch involved, that's simply a special case of a handler that marshalls the message and puts it on the shared queue, then (if it's synchronous) waits.
It's an indirect subroutine call, same overhead as calling a dynamically linked library.
The difference between a user-mode and kernel-mode NFS server is simply a matter of how you load the server.
Funny, all the 'big name' modern microkernels I'm aware of either currently exploit context separation, or they used to
Have you ever used one? What ones are you familiar with? Have you even studied one that wasn't an academic exercise, one actually designed for real work (that is, Mach and Minix don't count)?
if a property of microkernels isn't process separation,
Even a monolithic kernel doesn't have to have a separation between process address spaces. Process separation provides failure isolation and security, but there have been multitasking operating systems with both monolithic and microkernel design on processors that didn't implement a process separation mechanism at all.
If the components that you're dealing with are such that failure of one is catastrophic in any case, and they're all considered to be part of the same security boundary, then putting them in separate address spaces and processor contexts is silly.
In a monolithic kernel you have a distinction between components running in the same context and components running in separate contexts. One are called "threads" and the other "processes", and you have separate APIs for "threads" and "processes" to communicate with each other, and still more separate APIs for kernel threads and threads running in user processes.
In an ideal microkernel the distinction between "threads" and "processes" is simply a function of association. Sending a message to another thread in the same address space and one in another address space, or even across a security boundary, uses the same API, and all communication uses that API. The trade-off between fast message passing (which can take the same number of instructions and cycles as a subroutine call because it can be *implemented* as a subroutine call when using a queue-message-and-wait mechanism) and full-on "marshal a message and execute a context switch" (or even "marshal a message into network byte order and pass it to another processor in the cluster over the network") is a detail of implementation.
The distinction then is that in a microkernel things like "user space file systems" or "distributed file systems" is simply a matter of, at the most, recompiling the file system. The API remains the same.
In real microkernels you have complications from things like shared buffers, but still... moving a component from one place to another is a minor effort instead of a major redesign, and writing things like file systems and network drivers is enormously easier. On the Amiga there was a user-written NET: file system that was an application program that registered itself as a file system handler (mounting itself as NET:) and simply passed the messages it recieved over the message port to its counterpart on another system, and took received messages and passed them on as a proxy in return.
Asking "what's the difference between a microkernel and a monolithic kernel" is like asking "what's the difference between VMS and UNIX" or "Linux and OS/360". All the arguments people make against microkernels now were made against UNIX in the '70s. Having the user command processor as a separate program and creating a new process context for every command was considered utterly insane and inefficient, because creating a new process context on a typical mainframe or minicomputer OS was a tremendously expensive process. A UNIX process is so lightweight by comparison that the overhead of fork() and exec() is negligable compared to the overhead of opening a couple of files and reading them that it's lost in the noise.
(It's kind of ironic, actually, that the Linux ELF-based libc and the OSX Mach-O runtime and other dynamically loaded runtimes have brought all the crippling overhead of heavy process creation back... Moore's Law has hidden this, but comparing the overhead of a dynamically loaded ELF libc to a 6th edition a.out-based one makes the distinction between Linux and OSX look irrelevant by comparison)
I disagree that context separation is not a fundamental property of a bona fide microkernel;
Wikipedia isn't authoritative, and implementing a microkernel with physical address space separation makes as much sense as implementing a TCP stack by blindly following the ISO model and having separate modules for every layer... even if they don't do anything.
How would you build a microkernel on a system without an MMU? There's a lot of real-time microkernels that run on systems without an MMU like the Amiga Exec.
(Pick some random task) in a microkernel involves building a message / marshalling, while the same task in a monolithic kernel involves a direct function call.
A direct function call involves building a message (on the stack, or in registers) and executing a context switch (function call). If you're passing a message into the same process context and waiting, the overhead for actually queueing and dequeing a message is around 4 instructions, and if you inline the message passing the optimiser can eliminate that.
Spending money on what? You're confusing me or you're confused about something... why do you think OpenBSD costs me more than Linux?
If what you want is to have a record of any network activities
No, that's not why I use proxies.
I mean, thanks for the information about the Linux IP filter solution, even if I don't use it... but a TCP-based command connection is still something missing from Amanda. A persistent TCP-based connection would also allow Amanda to distinguish between failure modes better than it does now, because since UDP is connectionless a broken amandad isn't distinguishable from a dead or unroutable system.
allofmp3 is a Russian company taking advantage of Russian copyright law to avoid paying royalties to non-Russian artists. It makes the US labels seem benevolent by comparison.
Even if I was using Linux for my firewall, I'd still be using application layer proxies, not "stateful filtering" in the kernel. UDP without an application level proxy is no-go.
2.6.8? This is a development release of Amanda, then, since 2.5 just came out?
Bacula doesn't have Amanda's scheduling.
on
Amanda 2.5 Released
·
· Score: 4, Interesting
For me, the lack of automatic backup scheduling in other packages is a complete deal-breaker. Amanda, I just tell it how many full backups I want over what period, and it makes it happen. There's no "full backup this friday" crap. You don't have enough tape? It defers the backups it can, and lets you know you need to get more... it's painless.
For a site with growing storage there's no alternative to Amanda.
And beyond the moon, the asteroid belt is a much easier place to get raw materials from. Mars still looks like it has just enough atmosphere to be trouble, and not enough to really help... and it's got a deep gravity well.
Let's get established on the moon, then worry about the next step. I suspect that by the time we've solved the problems there, Mars won't be nearly so attractive.
The biggest thing I have problems with using Amanda is the need for a clean IP path to the destination, so I can't run a backup through a proxy firewall. Does the new version still use UDP for control?
The problem with Microkernels is that Mach has become the model for "what microkernels are".
Microkernels aren't about putting every component into its own memory and execution context.
Microkernels are about having a consistent API for both system and user components to communicate with. Typically you have a message queue, and standardised messages that can be (but not necessarily are) marshalled across address space boundaries.
There's no reason that a processor context switch has to happen, nor even that a message actually needs to be queued and dequeued in another thread, it just has to be possible for that to happen. When you make a call-with-wait (so you're suspended until the return packet gets back), the entire operation can happen in your own execution context.
OR, the operation could involve a round-trip across a network link.
The key is that the API doesn't distinguish between these two cases, it all depends on what's registered to handle that message.
So there's no reason a microkernel OS can't be as fast as a monolithic kernel. In fact microkernels an microkernel-like designs are not exactly rare in the control systems industry, where the performance and latency requirements are much tighter than they are in a desktop OS. The most microkernel-like personal computer OS, AmigaOS, was noted for its high performance and responsiveness.
Mach, no, that was a mistake. But microkernel design isn't the reason why.
Not likely. I've run OS 7 and NeXTstep on the same hardware... a 30 MHz 68000 with 16M RAM, and NeXTstep is much more responsive and capable. For that matter, NeXTstep is more responsive than OS 9 on my 7600/180, as soon as you have more than one application running.
I haven't run OS 6 on a Performa 475, but on an SE/30 there's not a huge difference between OS 6 and OS 7 unless you turn off Multifinder on OS 6... but I don't think anyone woudl put up with that.
Mac OS X does lose performance from the massively increased amount of CPU activity to render print-quality graphics for all windows, even when they're obscured, but not nearly enough to make up for the crippling effect of cooperative multitasking on classic Mac OS.
This is most likely the latest instance of the deep design flaw that the Microsoft HTML control has had since 1997, a flaw that no other browser (open source or commercial) suffers from, a flaw that Microsoft is going to have to break every application that uses the HTML control for anything but simple HTML display to fix... but which they absolutely have to do.
Compared to sendmail... this would be like Allman "fixing" the backdoor that the Internet Worm used by changing the password from "WIZARD" to "DEMON", then making patch after patch to keep the backdoor open... instead of simply taking it out as he did. Genuinely fixing a design flaw, rather than patching over instances of it, THAT is what "concentrating on security" means.
But if you can afford that, you can afford Delicious Libraryand a Mac mini to run it on.
Re:Good thing this is a workstation card
on
ATI's 1GB Video Card
·
· Score: 2, Informative
why the hell would anyone want 256mb of textures on an already stuttering GPU.
Because 90% of programming is an excersize in caching, and if you can just cache the textures you can let your GPU just get 'em instead of waiting for it to finish saying "g-g-g-give me a t-t-t-tex... t-t-text-t-t-... gimme a damn bitmap!"
So every single open source project in the world has been taken care of after the original creators moved on to other things?
I'm not talking about "every single open source project", or even "every single open source project associated with openbsd". I'm just talking about OpenSSH, but the same is true of any other open source project that has a significant amount of functionality.
there's no guarantee that someone will step up to the plate.
There's no guarantee that someone will step up to the plate if a commercial product is abandoned, either. The big difference is that with an open source project, you have the source too. You can support yourself, pay for someone to support you, or even become the entity that steps up to the plate. With commercial software you have no guarantee that the source code you need to do this will be available, either to you or even to a successor company that's bought the original company's assets, no matter how "important" the product seems to be.
I've been through this process multiple times, and it's never pleasant. Whether the company changes the thrust of their business, or is bought by a competitor and shut down, or simply decides that a product you were depending on has become unprofitable, the result is the same.
So, really, it's open source software that gives you the best chance of getting through a product's abandonment with your sanity and profits intact.
It was the Software Tools movement. It was Doctor Dobbs' Journal. It was net.sources. It was SIMTEL-20. It was Beagle Brothers and Tangible Software. It was everyone distributing software as source whether commercial or not.
If GPL fans are frustrated by Eric Raymond taking credit for something they think Stallman invented, they're just echoing the same frustration so many of the people who were already part of the movement feel towards Stallman. Raymond and Stallman have an awful lot in common, and as far as I'm concerned they deserve each other.
I just wish they'd leave the rest of us the hell alone. We don't need them.
If France is willing to force companies to open up digital content, why are they starting with music? After all, music consumers' livelihoods don't depend on their ability to play music, and it's not hard to find alternate sources for any piece of music they want to listen to.
They should start with software, and require major companies selling software in France make their products available to run on a variety of platforms? iTunes, Acrobat, any "market leader" like that... would have to be available on Windows, Macintosh, and Linux to sell in France...
There are open source programs that provide some of the functionality of commercial desktop software. The problem is that for business you need software that is bug-for-bug compatible. Yes, it's deeply wrong that Microsoft file formats are a mess equalled only by the Emacs undumper in pure evil non-compatibility in the open-source world... but that doesn't change the fact that bug-for-bug compatibility is needed.
The Gimp is a decent tool. There's better free software on the Mac, and none of it runs Photoshop plugins and filters.
People use operating systems to run applications. Even on the Mac, which has thousands of times the application base of Linux, the lack of Windows applications hurts... because getting someone to choose applications on the basis of the operating system they run is hard enough as it is...
I really hate how Richard Stallman and the FSF have hijacked the Free Software and Open Systems movement and attempted to mold it into what they see as ideal. But perhaps I'm reading their intentions incorrectly. If all they wanted to do was create a buzzword that would get misused and misquoted, they've succeeded. Seriously, there was a free software and open systems (which is not quite the same as open source, and definitely not the same as the FSF's idea of free software) movement before the GNU Manifesto, and the FSF used all the same Embrace and Extend techniques the Microsoft does to co-opt it. GCC was made deliberately incompatible with the C standard, with extensions that didn't actually provide new functionality... they just guaranteed that software written for GCC wouldn't compile on competing freely distributable compilers.
What they have done is show how you can give away your source code and still retain effective control over it, and use the resulting street cred to co-opt the work of thousands of developers who thought that by using the GPL they were "simply sharing their code". He's at least as responsible for the current confusion as Raymond.
Eric Raymond's got some really messed up ideas, too, and I agree that he's further muddied the waters... but Stallman's hardly innocent of stirring the pot himself.
Slashdot Mirror
Wow. You must share some of what you are smoking.
...
:math:linuxthreads:login:/usr/lib:/lib /opt/kde2/bin/konqueror -/
It's called "30 years in the real-time control systems industry".
I'm aware that a monolithic design doesn't need any kind of context separation
Neither does a microkernel design. The only microkernel designs that demand context separation are the "academic microkernels" producted by people who (I presume) looked at the way the real-time industry was doing stuff and thought "hey, that's really cool, and if we add context separation we can get something even undergrads can understand". It's no accident that the poster boys for "screwed up academic microkernels" are Mach (MIT) and Minix (VU).
network bridging kernel components [...] I can think of another technology that does this; it's called J2EE.
Also: NFS, Athena, Vice, Photon, Plan 9, half the NUMA and clustering systems in the world,
Building an entire kernel out of little queues is just insane and infeasible in the real world.
It's a common way of building a kernel in the real world: there's probably 100 installed real-time systems for every timeshared system out there, and microkernel design is hardly unusual there.
The cost of dynamic linking is typically very small
For today's computers, yes, but you're missing the point I'm making. OK, look:
[ecode]
gee:/builds/glibc/cross:[254]$ LD_DEBUG=statistics elf/ld-linux.so.2 --library-path
16634:
16634: runtime linker statistics:
16634: total startup time in dynamic loader: 699430072 clock cycles
16634: time needed for relocation: 694116497 clock cycles (99.2)
16634: number of relocations: 54130
16634: time needed to load objects: 4958742 clock cycles (.7)[/ecode]Seven hundred million clock cycles in the dynamic loader starting up Konqueror, almost all relocation. Elsewhere I'm finding over a million clock cycles just for ls. Prelinking gets it down to a "mere" few hundred thousand cycles.
That's acceptable today, but back in the period I'm talking about that would be several seconds for every command. For a mainframe operating system, several seconds startup time for an execution context wasn't a big deal... typical jobs didn't create new execution contexts on a regular basis. So the mainframe guys, with this idea that creating an execution context was expensive, looked at UNIX's fork()/exec() with horror. The UNIX guys, who'd gotten rid of most of the stuff that mainframe operating systems were doing, had this big battle convincing people that the time spent reading the FORTRAN compiler's image from disk was thousands of times greater than the time spent creating its process context to run in.
Similarly, you're looking at microkernel design with this idea that message passing involves taking a message, marshalling it into a flat format, copying it, making a system call, unmarshalling it, and making a subroutine call. It's like you're a mainframe guy who thinks that creating a new process context means IPLing a new copy of CMS into a VM partition.
In a high performance microkernel message passing involves taking a message, then either (for an asynchronous queue) adding it to a linked list and then later (possibly after several messages have been queued) performing a kernel thread switch, or (for a synchronous queue) calling the handler directly. If there's a context switch involved, that's simply a special case of a handler that marshalls the message and puts it on the shared queue, then (if it's synchronous) waits.
It's an indirect subroutine call, same overhead as calling a dynamically linked library.
The difference between a user-mode and kernel-mode NFS server is simply a matter of how you load the server.
Funny, all the 'big name' modern microkernels I'm aware of either currently exploit context separation, or they used to
Have you ever used one? What ones are you familiar with? Have you even studied one that wasn't an academic exercise, one actually designed for real work (that is, Mach and Minix don't count)?
if a property of microkernels isn't process separation,
Even a monolithic kernel doesn't have to have a separation between process address spaces. Process separation provides failure isolation and security, but there have been multitasking operating systems with both monolithic and microkernel design on processors that didn't implement a process separation mechanism at all.
If the components that you're dealing with are such that failure of one is catastrophic in any case, and they're all considered to be part of the same security boundary, then putting them in separate address spaces and processor contexts is silly.
In a monolithic kernel you have a distinction between components running in the same context and components running in separate contexts. One are called "threads" and the other "processes", and you have separate APIs for "threads" and "processes" to communicate with each other, and still more separate APIs for kernel threads and threads running in user processes.
In an ideal microkernel the distinction between "threads" and "processes" is simply a function of association. Sending a message to another thread in the same address space and one in another address space, or even across a security boundary, uses the same API, and all communication uses that API. The trade-off between fast message passing (which can take the same number of instructions and cycles as a subroutine call because it can be *implemented* as a subroutine call when using a queue-message-and-wait mechanism) and full-on "marshal a message and execute a context switch" (or even "marshal a message into network byte order and pass it to another processor in the cluster over the network") is a detail of implementation.
The distinction then is that in a microkernel things like "user space file systems" or "distributed file systems" is simply a matter of, at the most, recompiling the file system. The API remains the same.
In real microkernels you have complications from things like shared buffers, but still... moving a component from one place to another is a minor effort instead of a major redesign, and writing things like file systems and network drivers is enormously easier. On the Amiga there was a user-written NET: file system that was an application program that registered itself as a file system handler (mounting itself as NET:) and simply passed the messages it recieved over the message port to its counterpart on another system, and took received messages and passed them on as a proxy in return.
Asking "what's the difference between a microkernel and a monolithic kernel" is like asking "what's the difference between VMS and UNIX" or "Linux and OS/360". All the arguments people make against microkernels now were made against UNIX in the '70s. Having the user command processor as a separate program and creating a new process context for every command was considered utterly insane and inefficient, because creating a new process context on a typical mainframe or minicomputer OS was a tremendously expensive process. A UNIX process is so lightweight by comparison that the overhead of fork() and exec() is negligable compared to the overhead of opening a couple of files and reading them that it's lost in the noise.
(It's kind of ironic, actually, that the Linux ELF-based libc and the OSX Mach-O runtime and other dynamically loaded runtimes have brought all the crippling overhead of heavy process creation back... Moore's Law has hidden this, but comparing the overhead of a dynamically loaded ELF libc to a 6th edition a.out-based one makes the distinction between Linux and OSX look irrelevant by comparison)
I disagree that context separation is not a fundamental property of a bona fide microkernel;
Wikipedia isn't authoritative, and implementing a microkernel with physical address space separation makes as much sense as implementing a TCP stack by blindly following the ISO model and having separate modules for every layer... even if they don't do anything.
How would you build a microkernel on a system without an MMU? There's a lot of real-time microkernels that run on systems without an MMU like the Amiga Exec.
(Pick some random task) in a microkernel involves building a message / marshalling, while the same task in a monolithic kernel involves a direct function call.
A direct function call involves building a message (on the stack, or in registers) and executing a context switch (function call). If you're passing a message into the same process context and waiting, the overhead for actually queueing and dequeing a message is around 4 instructions, and if you inline the message passing the optimiser can eliminate that.
keep spending your money for naught...
Spending money on what? You're confusing me or you're confused about something... why do you think OpenBSD costs me more than Linux?
If what you want is to have a record of any network activities
No, that's not why I use proxies.
I mean, thanks for the information about the Linux IP filter solution, even if I don't use it... but a TCP-based command connection is still something missing from Amanda. A persistent TCP-based connection would also allow Amanda to distinguish between failure modes better than it does now, because since UDP is connectionless a broken amandad isn't distinguishable from a dead or unroutable system.
allofmp3 is a Russian company taking advantage of Russian copyright law to avoid paying royalties to non-Russian artists. It makes the US labels seem benevolent by comparison.
man Mach-O
Even if I was using Linux for my firewall, I'd still be using application layer proxies, not "stateful filtering" in the kernel. UDP without an application level proxy is no-go.
2.6.8? This is a development release of Amanda, then, since 2.5 just came out?
For me, the lack of automatic backup scheduling in other packages is a complete deal-breaker. Amanda, I just tell it how many full backups I want over what period, and it makes it happen. There's no "full backup this friday" crap. You don't have enough tape? It defers the backups it can, and lets you know you need to get more... it's painless.
For a site with growing storage there's no alternative to Amanda.
Does it support generalised backup apps, or do they still have to be wrapped in scripts to make them look like dump or tar?
We have unfinished business on the moon!
And beyond the moon, the asteroid belt is a much easier place to get raw materials from. Mars still looks like it has just enough atmosphere to be trouble, and not enough to really help... and it's got a deep gravity well.
Let's get established on the moon, then worry about the next step. I suspect that by the time we've solved the problems there, Mars won't be nearly so attractive.
The biggest thing I have problems with using Amanda is the need for a clean IP path to the destination, so I can't run a backup through a proxy firewall. Does the new version still use UDP for control?
The problem with Microkernels is that Mach has become the model for "what microkernels are".
Microkernels aren't about putting every component into its own memory and execution context.
Microkernels are about having a consistent API for both system and user components to communicate with. Typically you have a message queue, and standardised messages that can be (but not necessarily are) marshalled across address space boundaries.
There's no reason that a processor context switch has to happen, nor even that a message actually needs to be queued and dequeued in another thread, it just has to be possible for that to happen. When you make a call-with-wait (so you're suspended until the return packet gets back), the entire operation can happen in your own execution context.
OR, the operation could involve a round-trip across a network link.
The key is that the API doesn't distinguish between these two cases, it all depends on what's registered to handle that message.
So there's no reason a microkernel OS can't be as fast as a monolithic kernel. In fact microkernels an microkernel-like designs are not exactly rare in the control systems industry, where the performance and latency requirements are much tighter than they are in a desktop OS. The most microkernel-like personal computer OS, AmigaOS, was noted for its high performance and responsiveness.
Mach, no, that was a mistake. But microkernel design isn't the reason why.
Not likely. I've run OS 7 and NeXTstep on the same hardware... a 30 MHz 68000 with 16M RAM, and NeXTstep is much more responsive and capable. For that matter, NeXTstep is more responsive than OS 9 on my 7600/180, as soon as you have more than one application running.
I haven't run OS 6 on a Performa 475, but on an SE/30 there's not a huge difference between OS 6 and OS 7 unless you turn off Multifinder on OS 6... but I don't think anyone woudl put up with that.
Mac OS X does lose performance from the massively increased amount of CPU activity to render print-quality graphics for all windows, even when they're obscured, but not nearly enough to make up for the crippling effect of cooperative multitasking on classic Mac OS.
*sigh*
This is most likely the latest instance of the deep design flaw that the Microsoft HTML control has had since 1997, a flaw that no other browser (open source or commercial) suffers from, a flaw that Microsoft is going to have to break every application that uses the HTML control for anything but simple HTML display to fix... but which they absolutely have to do.
Compared to sendmail... this would be like Allman "fixing" the backdoor that the Internet Worm used by changing the password from "WIZARD" to "DEMON", then making patch after patch to keep the backdoor open... instead of simply taking it out as he did. Genuinely fixing a design flaw, rather than patching over instances of it, THAT is what "concentrating on security" means.
I wish I could afford that problem.
But if you can afford that, you can afford Delicious Library and a Mac mini to run it on.
why the hell would anyone want 256mb of textures on an already stuttering GPU.
Because 90% of programming is an excersize in caching, and if you can just cache the textures you can let your GPU just get 'em instead of waiting for it to finish saying "g-g-g-give me a t-t-t-tex... t-t-text-t-t-... gimme a damn bitmap!"
OpenGL had it's chance to be the 3d API on windows, and blew it causing MS to develop DirectX.
Erm...
Up until Microsoft deliberately broke OpenGL for multiple video cards, killing OpenGL for flight simulators, OpenGL was *it*.
OpenGL didn't "blow it", it was blown out of the water by standard Microsoft monopoly tacticts.
So every single open source project in the world has been taken care of after the original creators moved on to other things?
I'm not talking about "every single open source project", or even "every single open source project associated with openbsd". I'm just talking about OpenSSH, but the same is true of any other open source project that has a significant amount of functionality.
there's no guarantee that someone will step up to the plate.
There's no guarantee that someone will step up to the plate if a commercial product is abandoned, either. The big difference is that with an open source project, you have the source too. You can support yourself, pay for someone to support you, or even become the entity that steps up to the plate. With commercial software you have no guarantee that the source code you need to do this will be available, either to you or even to a successor company that's bought the original company's assets, no matter how "important" the product seems to be.
I've been through this process multiple times, and it's never pleasant. Whether the company changes the thrust of their business, or is bought by a competitor and shut down, or simply decides that a product you were depending on has become unprofitable, the result is the same.
So, really, it's open source software that gives you the best chance of getting through a product's abandonment with your sanity and profits intact.
By the standards of most of the world, both the Republicans and the Democrats would qualify as right of center.
it's free software, so someone else can pick up the pieces after Theo is forced to take his toys and go home
Someone else will take on the work and cost of supporting OpenSSH. There's no "maybe" about it.
They didn't "create the movement".
The movement was already there.
It was already huge.
It was the Software Tools movement. It was Doctor Dobbs' Journal. It was net.sources. It was SIMTEL-20. It was Beagle Brothers and Tangible Software. It was everyone distributing software as source whether commercial or not.
If GPL fans are frustrated by Eric Raymond taking credit for something they think Stallman invented, they're just echoing the same frustration so many of the people who were already part of the movement feel towards Stallman. Raymond and Stallman have an awful lot in common, and as far as I'm concerned they deserve each other.
I just wish they'd leave the rest of us the hell alone. We don't need them.
If France is willing to force companies to open up digital content, why are they starting with music? After all, music consumers' livelihoods don't depend on their ability to play music, and it's not hard to find alternate sources for any piece of music they want to listen to.
They should start with software, and require major companies selling software in France make their products available to run on a variety of platforms? iTunes, Acrobat, any "market leader" like that... would have to be available on Windows, Macintosh, and Linux to sell in France...
There are open source programs that provide some of the functionality of commercial desktop software. The problem is that for business you need software that is bug-for-bug compatible. Yes, it's deeply wrong that Microsoft file formats are a mess equalled only by the Emacs undumper in pure evil non-compatibility in the open-source world... but that doesn't change the fact that bug-for-bug compatibility is needed.
The Gimp is a decent tool. There's better free software on the Mac, and none of it runs Photoshop plugins and filters.
People use operating systems to run applications. Even on the Mac, which has thousands of times the application base of Linux, the lack of Windows applications hurts... because getting someone to choose applications on the basis of the operating system they run is hard enough as it is...
I really hate how Richard Stallman and the FSF have hijacked the Free Software and Open Systems movement and attempted to mold it into what they see as ideal. But perhaps I'm reading their intentions incorrectly. If all they wanted to do was create a buzzword that would get misused and misquoted, they've succeeded. Seriously, there was a free software and open systems (which is not quite the same as open source, and definitely not the same as the FSF's idea of free software) movement before the GNU Manifesto, and the FSF used all the same Embrace and Extend techniques the Microsoft does to co-opt it. GCC was made deliberately incompatible with the C standard, with extensions that didn't actually provide new functionality... they just guaranteed that software written for GCC wouldn't compile on competing freely distributable compilers.
What they have done is show how you can give away your source code and still retain effective control over it, and use the resulting street cred to co-opt the work of thousands of developers who thought that by using the GPL they were "simply sharing their code". He's at least as responsible for the current confusion as Raymond.
Eric Raymond's got some really messed up ideas, too, and I agree that he's further muddied the waters... but Stallman's hardly innocent of stirring the pot himself.