Cron and init and rc.X work fine, I'm not a hater. However I do think it's time to move forward.
Fine, I'll bite. Here's why you're just talking out of your ass.
* Use XML for configuration, it's easy to parse, it's here to stay and I think it's a little bit better than the columns of a crontab because it's more verbose.
Ok, everyone, repeat after me, XML is *not* easy to parse. I don't understand why anyone says this. Write an XML parser. No, not some silly thing you did for some crappy college project but a real XML parser that supports namespaces, various encoding types, DTD validation, etc.
The problem with having a standard like XML is that at this point, it's incredibly heavy-weight. Hell, there's even a standard API (Dom) that's a pain in the ass for every language I've ever tried to use it for.
* Have variable restart behavior, restart, restart and restart dependancies, reboot, just let processes die, etc..
Dependencies are hiearchical. Do you mean restart everything that depends on process? That's already in, at least, the Gentoo init scripts.
* Have dependancies (start the database before the shit that inserts data in to it, even though it shouldn't matter, it does) and start them in the right order.
This is supported in a lot of init scripts including Gentoo's.
* Kill dependencies when I kill a process
Again, it's in Gentoo's scripts at least.
* Smart killing, if something doesn't gracefully go down, 9 it down.
kill -9 is never a good idea. You're dancing with the devil if you do this. You risk massive corruption of your system.
* Have some kind of health monitoring call back, at a time I specify, execute a program that will check to see if a process is okay.
This is a feature of launchd. However, I'm not a huge fan. I don't think it will help. Most apps would probably just spawn another thread to respond to these things. If another thread got hung, you would never know.
* Once all this is done, maybe support something like soft cycling, kill everything down to single user mode and then bring it all back.
It's called the 'init' command. You can already do this.
* Variable dependency notification, if I restart my database allow me to do nothing to dependant processes, restart them, or HUP them, or something I define.
You can modify the startup scripts to implement whatever behavior you want.
* Full featured logging.
As opposed to...? Have you not heard of syslog?
* At some configurable interval, sniff out all of the XML configs in this "next gen startup proc" config directory, like every 5 minutes just check for changes and if needed, start something new up.
How do you know whether when you look at the files, they aren't in an inconsistent state? Say you've got vi open on a file (and I bet you use vi) and in the process of editting and haven't closed a tag you're entering but you save because you've made a lot of other changes. What happens when the config is now reread?
* Allow for user to be specified in the config
This is already supported. See/etc/conf.d on Gentoo.
* Allow for end users to have thier own daemons defined by files in their home directories.* Then finally, allow for cron like behavior and run tranient tasks with all the flexibility of cron.
Why even bother combining? What benefit do you get?
* Proc specific ulimits would be nice also...
ulimits on what??
* And some form of runlevel logic still.
So, reinvent what we already have?
* And startup and kill in parallel if allowed by the depends...
Gentoo supports this.
* And it should have a template for common daemon type things I should just provide a startup command, arguments, a user to run it as, and a r
No, you don't get it. Why in hell would you want to write yet another config file parser and use your own awkward config format when you could use standard XML and that very same parser that's already loaded to system RAM as a shared lib?
By it, I mean what the Unix community's needs are. I made this comment regarding the story's suggestion that other Unices may adopt this. Regardless of whether you think XML is the right solution, it seems obvious that the majority of the Unix community would probably not want XML to be used at such a fundamental part of their system's startup.
I don't think Apple's every considered, Hey, we should make this Open Source and incorporate requirements other Unices are probably going to have. They probably threw together something they needed and then decided to Open Source it. That's fine, they don't have to do anything other than that.
Re:Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 2, Insightful
The fundamental problem launchd was created to solve is system startup time. Twenty or thirty seconds to boot a freakin' laptop is just absurd. So we used launchd to get that down to four.
You can do parallel startup on most systems these days. Is there any reason why a daemon is necessary to improve startup time? Are shell scripts really that slow?
But beyond that, launchd also takes care of the problem of having six different types of configuration files, none of which are self-documenting or self-validating. A launchd configuration file can be validated and, if invalid (like somebody inserted a typographical error, or the file got truncated or something), discarded without interfering with system startup. That makes the system more resilient.
So it's fair to say that problems in shell scripts (that are based on syntax) are hard to isolate. I'll give you that. But why XML over say something like INI or a much simplier format?
XML is very heavy-weight (especially if you're validating it against a schema). It also quickly becomes unreadable. Startup scripts have always historically been hand-editable and hand-maintainable. While XML can be hand-edited, it's ugly and cumbersome.
I guess the typical Mac user won't care. XML configuration files are probably going to be the biggest thing keeping other Unices from picking launchd up.
Not a cron replacement, a init replacement
on
Does launchd Beat cron?
·
· Score: 5, Informative
Simply referring to launchd as a cron replacement is a major understatement. launchd runs as the init process and according to TFA was primarily made to replace the/etc/rc.d scripts during startup.
This is somewhat understandable for something like OS X. Doing something simple like displaying a GUI detailing startup is terribly difficult with/etc/rc.d scripts (considering the length of pause an fsck would take--users would certainly assume there system hung during boot).
I'm not sure launchd is something you'd want in 99% of Linux installs but if you're looking for a end-to-end user-oriented desktop I can see how a technology like this is necessary.
I'm not sure Apple Gets It though. Why in the world would they use XML configs? Gesh.
I remember many years ago when Microsoft first started acknowledging Linux as a threat someone posted on Slashdot drawing a parrallel between the 5 stages of grief and Microsoft's approach to Open Source. The similiarity is scary.
Denial You all might not remember this, but Microsoft reps used to pretend to know even know what Linux was in front of the press (while internal memos were circulating about it).
Anger Most remember that Microsoft took a very hostile position toward Linux saying all sorts of things about communism, terrorism, etc. They've admitted they were wrong about this campaign.
Bargaining I think this is where we are now.
Depression Something tells me if Longhorn flops, Microsoft's not going to be a very nice place to be at.
Acceptance OpenWindows in 2010? Who knows. Would you have expected OpenSolaris in 2005 back in 2000?
Perhaps you could inform us. Are there such thing are brand laws? I know there are trademark laws--but I would presume that "Tiger" is too generic of a term to be trademarked.
I know a half dozen types of Unix, but I don't know "X" Unx.
Six Unices eh? Ok, I'll bite, let's assume that you know Linux, FreeBSD, Solaris, SCO, NetBSD, and FreeBSD.
Now there's someone looking for someone to admin a network of 100 HP-UX machines. Guess what? HP-UX is sufficiently different from all of the above that it will take you a fair amount of time to learn it. Sorry pal, I agree with the employer here.
Or, if you know, say Java, C, Pascal and a few otehr langauges...and they are looking for C++, chances are, you can pick it up in a few weeks.
Really? C++ in a few weeks? So you could master the detailed workings of metatemplate programming, the sublities of C++'s various flavors of inheritence?
If you have 5+ years of experience in C or Java, that doesn't equate to 5+ years of experience in C++.
The attitude you express is dangerous. The worst thing for a project is when the people involved don't understand what they don't understand. That's how projects fail.
I put Gentoo on a VIA based system with 32M of ram. It was the perfect distro b/c I was able to put the very minimal amount of software on it with Cyrix specific optimizations--something no other distro could offer.
If I have a kick ass idea, do you think my first thought is "hmmm, I should give this away and get good Karma!" or "Hey, cool, I could sell this and make a million bucks!". Hmmm, lets see.... Karma.. or.. A Million Dollars? I'll take the $$ every time.
Money cannot buy happiness. You need money to survive and that's how I view it. If have have a good idea, the thing I do is share it with the people that I respect (and see whether they can shoot holes in it--which they often do).
If it remains a good idea, I try to figure out I can help the world with it.
I've got a job, and make enough money through it. I don't care about money anymore. I kind of view the OP's mentality of "I could make a million bucks" as sad. It's a bit arrogant really. You're idea is probably only moderately interesting.
Best thing to do is share it with the community. It may be able to play a small part in something that is really worth while.
A language, as bloated as a language could be, with lots of cool features on the language level, but ommitting the two most important aspects, a good standardized classlib which covers all important application scope aspects, and a language which is actually usable without having to fight with it for years before being able to master it to a certain degree.
I'm a C programmer by trade but use C++ a lot for various bits of research I do. I use C++ because it has some amazingly powerful constructs that no other language as popular as it has.
As far as complexity goes, yeah, C++ is complicated, but so is Java. The other day I was forced to write a simple application in Java. I could not believe what I had to do to just trap a mouse click. I had to create an anonymous inner class that subclassed an adapter class and then had to rely on the nested class scoping semantics to dispatch to one of my own member functions.
It was downright scary. I firmly believe Java's success was 99% marketing. I once heard Strousup comment that Sun spent 10 million on marketing Java in the first year whereas C++ entire development cost was well under a million.
I have a shirt from Sun that says "From 0 to 2.5 million in 5 years." Languages don't just spread like that without significant driving forces.
While it is indeed cool, just a little warning. This isn't 100% finalised yet (although to be honest it is 99% finalised)
Indeed. These libraries though are, at least, partially derived from the boost libraries and the boost libraries have had these features for quite some time.
Also, it's a little weird and non-idiomatic for C++ that the OP chose to declare variables well before their first use. This is shorter and for me (and probably most C++ coders) a little clearer.
std::tr1::function<int (int, int)> f = foo;
f(2, 3);
std::tr1::function<int (int)> g = std::tr1::bind(f, _1, 3);
g(2);
I guess I was a little too excited wrt the f(2) instead of g(2). And yes, delaying variable declaration is more natural. I didn't copy and paste actual code for fear of slashdot's lameness filter.
Windows NT OSes don't rely on a BIOS (at least the legacy PC definition of a BIOS) - for example, LinuxBIOS already can boot those operating systems having no real-mode support whatsoever.
Can you provide a reference to this? My understanding is that LinuxBIOS implements enough of the legacy BIOS that it can boot Windows NT. I'm quite sure that Windows requires real mode during boot up.
I've seen a lot of very smart people make this claim too...
Gee, if Linux/Microsoft is so brittle that it cannot protect itself from a hostile client, people shouldn't use it either.
Yup. If you don't have the latest patches on either a Linux or Windows machine then you should not have it connected to a network running anything that you rely on.
Company's spend a lot of money keeping up-to-date to ensure that Linux/Windows machines can protect themselves against hostile clients.
I'm surprised noone's mention the inclusion of the C++ TR1. There's a ton of very cool new library features. Here are my two favorite:
#include <tr1/functional>
int foo(int x, int y) { return x * y; }
using namespace std::tr1::placeholders;
int main() {
std::tr1::function<int (int, int)> f;
std::tr1::function<int (int)> g;
// f can be stored in a container
f = foo;
f(2, 3);
g = std::tr1::bind(f, _1, 3);
// this is equivalent to f(2, 3)
f(2) }
Not to mention the inclusion of shared_ptr which provides a reference counted pointer wrapper. This will eliminate 99% of the need to do manual memory management in C++. It's all very exciting, kudus to the G++ team on this!
One of the reasons BK kept their stuff closed was so they could take accountability if anything went wrong and now exactly how every client was accessing it. That's one of the advantages most managers see with going with a commercial company rather than a OSS solution.
This isn't just copying functionality, it's putting a widely used system at risk because you don't agree with their practices. That's the same philosophy espoused by a lot of virus writers.
You're kidding right? If the BK system is so brittle that it cannot protect itself against a hostile client then it should not be hosting any source code.
If a friendly client (trying to obtain interoperability) can fundamentally break a server, just imagine what a script kiddie would do..
What do you mean by "full virtualization"? Xen cannot run windows or any other "unmodified" OS as a guest, so I don't think it provides full virtualization at all, to me that means that you can run an unmodified OS as if it were a full x86 system.
Actually, it can run an unmodified Linux guest using on hardware that supports Intel's VMX virtualization extensions (not generally available yet). Windows is a bit more tricky because it relies on having an actual BIOS.
* fully virtualising x86 in software results in rather painful performance hits for many workloads and a very complex hypervisor
Something I think Sam missed is that Xen also supports VT which provides full-virtualization on the x86 (which makes Xen undeniably a true-hypervisor).
Compiler-driven para-virtualization is an interesting emerging area of research too that should make porting OSes to Xen much simplier.
All we need now is a really cool hypervisor-aware file system.. like a XenFS;-)
If Linus (and the others at OSDL) had been using the full pay-version, there would have been no problems.
No, the problem is that the Free and Commercial licenses expressly prohibit the reverse engineering of BitKeeper's protocol.
Since Linus works for OSDL, OSDL has the license for BitKeeper. If anyone violates the license (by reverse engineering), all of OSDL loses the license.
Larry has offered to comp Linus and Andrew a commercial license if they leave OSDL. Tell me he's not trying to strong-arm here. Who runs Linux, Linus, or Larry?
1) Linus has admitted using plenty of closed source software in the past. (How was he playing those DVDs?) and unlike RMS and a lot of other major philosophical kooks, Linus is a reasonable man.
2) There is nothing else that even comes close to being as usable and productive on Linux as Linus has recently pointed out.
1) Bill Gates is a reasonable man--unlike RMS and all of those other philosophical kooks. He uses the right tool for the job--regardless of whether it's Open or Closed Source.
2) There is nothing that even comes close to being as usable and productive as Windows as any study has put out.
Therefore by your logic there's no reason the EU should be forcing Microsoft to share their protocol specs with Open Source projects--in fact, it should protect Microsoft from all of those "bad apples" that are reverse engineering their products.
Hypocrits. This is an instance of sunshine-Linux users. There was a time, which most of you probably weren't around for, when Linux was not the best at anything. If there were limitations on reverse engineering FAT, or reverse engineering common hardware drivers, or even reverse engineering the BIOS interfaces Linux would not exist today.
You have a girl who worked at a company on the side where she had access to sensitive information about professors (and many other individuals). She steals that sensitive information and uses it to reset the password of the professors.
She then logs in to the grading system and changes her grades.
And the computer system worked like a charm. Any grade change resulted in a departmental notification. The professor, realizing that he did not make the change and could not log into the account any more, notified the appropriate authorities.
An investigation occurred and this criminal was discovered. Sounds like an open and shut case to me.
If a resolution is to be passed, these five members must all agree to it otherwise it doesn't happen. This gives them a great deal of power.
Only a security council resolution. The security council does not deal with these sort of issues. This would probably fall under EcoSoc. Of course, issues like this can always be discussed in the General Assembly.
The security council has some pretty crazy powers though and can pretty much stalemate anything. However, being a part of the big 5 doesn't mean you can veto *any* UN resolution. You'd have to convince the rest of the security council members to get involved.
To affect the type of change you are suggesting would require a Herculean buy-in that no one would be prepared to make in my opinion.
I understand what you're saying. I guess I should have made it clear in my post that I didn't expect this to happen anytime in the near future (read hundreds of years).
Pragmatically, it is likely that we will see, in our lifetimes, deprecation of some of the more esoteric usages of English in common conversation (whom is all but gone from most people's vocabularies for instance).
Slashdot Mirror
We're not talking about excellence here. We're talking about the difference between:Verses:If they would have just went with the later, the community might have picked up their work. Now, they'll maintain it forever.
I think if they Got It, they would have chosen the later.
Cron and init and rc.X work fine, I'm not a hater. However I do think it's time to move forward.
/etc/conf.d on Gentoo.
Fine, I'll bite. Here's why you're just talking out of your ass.
* Use XML for configuration, it's easy to parse, it's here to stay and I think it's a little bit better than the columns of a crontab because it's more verbose.
Ok, everyone, repeat after me, XML is *not* easy to parse. I don't understand why anyone says this. Write an XML parser. No, not some silly thing you did for some crappy college project but a real XML parser that supports namespaces, various encoding types, DTD validation, etc.
The problem with having a standard like XML is that at this point, it's incredibly heavy-weight. Hell, there's even a standard API (Dom) that's a pain in the ass for every language I've ever tried to use it for.
* Have variable restart behavior, restart, restart and restart dependancies, reboot, just let processes die, etc..
Dependencies are hiearchical. Do you mean restart everything that depends on process? That's already in, at least, the Gentoo init scripts.
* Have dependancies (start the database before the shit that inserts data in to it, even though it shouldn't matter, it does) and start them in the right order.
This is supported in a lot of init scripts including Gentoo's.
* Kill dependencies when I kill a process
Again, it's in Gentoo's scripts at least.
* Smart killing, if something doesn't gracefully go down, 9 it down.
kill -9 is never a good idea. You're dancing with the devil if you do this. You risk massive corruption of your system.
* Have some kind of health monitoring call back, at a time I specify, execute a program that will check to see if a process is okay.
This is a feature of launchd. However, I'm not a huge fan. I don't think it will help. Most apps would probably just spawn another thread to respond to these things. If another thread got hung, you would never know.
* Once all this is done, maybe support something like soft cycling, kill everything down to single user mode and then bring it all back.
It's called the 'init' command. You can already do this.
* Variable dependency notification, if I restart my database allow me to do nothing to dependant processes, restart them, or HUP them, or something I define.
You can modify the startup scripts to implement whatever behavior you want.
* Full featured logging.
As opposed to...? Have you not heard of syslog?
* At some configurable interval, sniff out all of the XML configs in this "next gen startup proc" config directory, like every 5 minutes just check for changes and if needed, start something new up.
How do you know whether when you look at the files, they aren't in an inconsistent state? Say you've got vi open on a file (and I bet you use vi) and in the process of editting and haven't closed a tag you're entering but you save because you've made a lot of other changes. What happens when the config is now reread?
* Allow for user to be specified in the config
This is already supported. See
* Allow for end users to have thier own daemons defined by files in their home directories.* Then finally, allow for cron like behavior and run tranient tasks with all the flexibility of cron.
Why even bother combining? What benefit do you get?
* Proc specific ulimits would be nice also...
ulimits on what??
* And some form of runlevel logic still.
So, reinvent what we already have?
* And startup and kill in parallel if allowed by the depends...
Gentoo supports this.
* And it should have a template for common daemon type things I should just provide a startup command, arguments, a user to run it as, and a r
No, you don't get it. Why in hell would you want to write yet another config file parser and use your own awkward config format when you could use standard XML and that very same parser that's already loaded to system RAM as a shared lib?
By it, I mean what the Unix community's needs are. I made this comment regarding the story's suggestion that other Unices may adopt this. Regardless of whether you think XML is the right solution, it seems obvious that the majority of the Unix community would probably not want XML to be used at such a fundamental part of their system's startup.
I don't think Apple's every considered, Hey, we should make this Open Source and incorporate requirements other Unices are probably going to have. They probably threw together something they needed and then decided to Open Source it. That's fine, they don't have to do anything other than that.
The fundamental problem launchd was created to solve is system startup time. Twenty or thirty seconds to boot a freakin' laptop is just absurd. So we used launchd to get that down to four.
You can do parallel startup on most systems these days. Is there any reason why a daemon is necessary to improve startup time? Are shell scripts really that slow?
But beyond that, launchd also takes care of the problem of having six different types of configuration files, none of which are self-documenting or self-validating. A launchd configuration file can be validated and, if invalid (like somebody inserted a typographical error, or the file got truncated or something), discarded without interfering with system startup. That makes the system more resilient.
So it's fair to say that problems in shell scripts (that are based on syntax) are hard to isolate. I'll give you that. But why XML over say something like INI or a much simplier format?
XML is very heavy-weight (especially if you're validating it against a schema). It also quickly becomes unreadable. Startup scripts have always historically been hand-editable and hand-maintainable. While XML can be hand-edited, it's ugly and cumbersome.
I guess the typical Mac user won't care. XML configuration files are probably going to be the biggest thing keeping other Unices from picking launchd up.
Simply referring to launchd as a cron replacement is a major understatement. launchd runs as the init process and according to TFA was primarily made to replace the /etc/rc.d scripts during startup.
/etc/rc.d scripts (considering the length of pause an fsck would take--users would certainly assume there system hung during boot).
This is somewhat understandable for something like OS X. Doing something simple like displaying a GUI detailing startup is terribly difficult with
I'm not sure launchd is something you'd want in 99% of Linux installs but if you're looking for a end-to-end user-oriented desktop I can see how a technology like this is necessary.
I'm not sure Apple Gets It though. Why in the world would they use XML configs? Gesh.
I remember many years ago when Microsoft first started acknowledging Linux as a threat someone posted on Slashdot drawing a parrallel between the 5 stages of grief and Microsoft's approach to Open Source. The similiarity is scary.
Denial
You all might not remember this, but Microsoft reps used to pretend to know even know what Linux was in front of the press (while internal memos were circulating about it).
Anger
Most remember that Microsoft took a very hostile position toward Linux saying all sorts of things about communism, terrorism, etc. They've admitted they were wrong about this campaign.
Bargaining
I think this is where we are now.
Depression
Something tells me if Longhorn flops, Microsoft's not going to be a very nice place to be at.
Acceptance
OpenWindows in 2010? Who knows. Would you have expected OpenSolaris in 2005 back in 2000?
Perhaps you could inform us. Are there such thing are brand laws? I know there are trademark laws--but I would presume that "Tiger" is too generic of a term to be trademarked.
What laws would Apple be breaking here?
I know a half dozen types of Unix, but I don't
know "X" Unx.
Six Unices eh? Ok, I'll bite, let's assume that you know Linux, FreeBSD, Solaris, SCO, NetBSD, and FreeBSD.
Now there's someone looking for someone to admin a network of 100 HP-UX machines. Guess what? HP-UX is sufficiently different from all of the above that it will take you a fair amount of time to learn it. Sorry pal, I agree with the employer here.
Or, if you know, say Java, C, Pascal and a few otehr langauges...and they are looking for C++, chances are, you can pick it up in a few weeks.
Really? C++ in a few weeks? So you could master the detailed workings of metatemplate programming, the sublities of C++'s various flavors of inheritence?
If you have 5+ years of experience in C or Java, that doesn't equate to 5+ years of experience in C++.
The attitude you express is dangerous. The worst thing for a project is when the people involved don't understand what they don't understand. That's how projects fail.
I put Gentoo on a VIA based system with 32M of ram. It was the perfect distro b/c I was able to put the very minimal amount of software on it with Cyrix specific optimizations--something no other distro could offer.
Took a while to build, but what do I care.
If I have a kick ass idea, do you think my first thought is "hmmm, I should give this away and get good Karma!" or "Hey, cool, I could sell this and make a million bucks!". Hmmm, lets see.... Karma.. or .. A Million Dollars? I'll take the $$ every time.
Money cannot buy happiness. You need money to survive and that's how I view it. If have have a good idea, the thing I do is share it with the people that I respect (and see whether they can shoot holes in it--which they often do).
If it remains a good idea, I try to figure out I can help the world with it.
I've got a job, and make enough money through it. I don't care about money anymore. I kind of view the OP's mentality of "I could make a million bucks" as sad. It's a bit arrogant really. You're idea is probably only moderately interesting.
Best thing to do is share it with the community. It may be able to play a small part in something that is really worth while.
A language, as bloated as a language could be, with lots of cool features on the language level, but ommitting the two most important aspects, a good standardized classlib which covers all important application scope aspects, and a language which is actually usable without having to fight with it for years before being able to master it to a certain degree.
I'm a C programmer by trade but use C++ a lot for various bits of research I do. I use C++ because it has some amazingly powerful constructs that no other language as popular as it has.
As far as complexity goes, yeah, C++ is complicated, but so is Java. The other day I was forced to write a simple application in Java. I could not believe what I had to do to just trap a mouse click. I had to create an anonymous inner class that subclassed an adapter class and then had to rely on the nested class scoping semantics to dispatch to one of my own member functions.
It was downright scary. I firmly believe Java's success was 99% marketing. I once heard Strousup comment that Sun spent 10 million on marketing Java in the first year whereas C++ entire development cost was well under a million.
I have a shirt from Sun that says "From 0 to 2.5 million in 5 years." Languages don't just spread like that without significant driving forces.
While it is indeed cool, just a little warning. This isn't 100% finalised yet (although to be honest it is 99% finalised)
Indeed. These libraries though are, at least, partially derived from the boost libraries and the boost libraries have had these features for quite some time.
Windows NT OSes don't rely on a BIOS (at least the legacy PC definition of a BIOS) - for example, LinuxBIOS already can boot those operating systems having no real-mode support whatsoever.
Can you provide a reference to this? My understanding is that LinuxBIOS implements enough of the legacy BIOS that it can boot Windows NT. I'm quite sure that Windows requires real mode during boot up.
I've seen a lot of very smart people make this claim too...
Gee, if Linux/Microsoft is so brittle that it cannot protect itself from a hostile client, people shouldn't use it either.
Yup. If you don't have the latest patches on either a Linux or Windows machine then you should not have it connected to a network running anything that you rely on.
Company's spend a lot of money keeping up-to-date to ensure that Linux/Windows machines can protect themselves against hostile clients.
One of the reasons BK kept their stuff closed was so they could take accountability if anything went wrong and now exactly how every client was accessing it. That's one of the advantages most managers see with going with a commercial company rather than a OSS solution.
This isn't just copying functionality, it's putting a widely used system at risk because you don't agree with their practices. That's the same philosophy espoused by a lot of virus writers.
You're kidding right? If the BK system is so brittle that it cannot protect itself against a hostile client then it should not be hosting any source code.
If a friendly client (trying to obtain interoperability) can fundamentally break a server, just imagine what a script kiddie would do..
What do you mean by "full virtualization"? Xen cannot run windows or any other "unmodified" OS as a guest, so I don't think it provides full virtualization at all, to me that means that you can run an unmodified OS as if it were a full x86 system.
Actually, it can run an unmodified Linux guest using on hardware that supports Intel's VMX virtualization extensions (not generally available yet). Windows is a bit more tricky because it relies on having an actual BIOS.
This is all in the unstable branch.
* fully virtualising x86 in software results in rather painful performance hits for many workloads and a very complex hypervisor
;-)
Something I think Sam missed is that Xen also supports VT which provides full-virtualization on the x86 (which makes Xen undeniably a true-hypervisor).
Compiler-driven para-virtualization is an interesting emerging area of research too that should make porting OSes to Xen much simplier.
All we need now is a really cool hypervisor-aware file system.. like a XenFS
Yup, every system I have access to (including a T41p that I'm writing this message on) run Xen just fine.
If Linus (and the others at OSDL) had been using the full pay-version, there would have been no problems.
No, the problem is that the Free and Commercial licenses expressly prohibit the reverse engineering of BitKeeper's protocol.
Since Linus works for OSDL, OSDL has the license for BitKeeper. If anyone violates the license (by reverse engineering), all of OSDL loses the license.
Larry has offered to comp Linus and Andrew a commercial license if they leave OSDL. Tell me he's not trying to strong-arm here. Who runs Linux, Linus, or Larry?
1) Linus has admitted using plenty of closed source software in the past. (How was he playing those DVDs?) and unlike RMS and a lot of other major philosophical kooks, Linus is a reasonable man.
2) There is nothing else that even comes close to being as usable and productive on Linux as Linus has recently pointed out.
1) Bill Gates is a reasonable man--unlike RMS and all of those other philosophical kooks. He uses the right tool for the job--regardless of whether it's Open or Closed Source.
2) There is nothing that even comes close to being as usable and productive as Windows as any study has put out.
Therefore by your logic there's no reason the EU should be forcing Microsoft to share their protocol specs with Open Source projects--in fact, it should protect Microsoft from all of those "bad apples" that are reverse engineering their products.
Hypocrits. This is an instance of sunshine-Linux users. There was a time, which most of you probably weren't around for, when Linux was not the best at anything. If there were limitations on reverse engineering FAT, or reverse engineering common hardware drivers, or even reverse engineering the BIOS interfaces Linux would not exist today.
You have a girl who worked at a company on the side where she had access to sensitive information about professors (and many other individuals). She steals that sensitive information and uses it to reset the password of the professors.
She then logs in to the grading system and changes her grades.
And the computer system worked like a charm. Any grade change resulted in a departmental notification. The professor, realizing that he did not make the change and could not log into the account any more, notified the appropriate authorities.
An investigation occurred and this criminal was discovered. Sounds like an open and shut case to me.
If a resolution is to be passed, these five members must all agree to it otherwise it doesn't happen. This gives them a great deal of power.
Only a security council resolution. The security council does not deal with these sort of issues. This would probably fall under EcoSoc. Of course, issues like this can always be discussed in the General Assembly.
The security council has some pretty crazy powers though and can pretty much stalemate anything. However, being a part of the big 5 doesn't mean you can veto *any* UN resolution. You'd have to convince the rest of the security council members to get involved.
To affect the type of change you are suggesting would require a Herculean buy-in that no one would be prepared to make in my opinion.
I understand what you're saying. I guess I should have made it clear in my post that I didn't expect this to happen anytime in the near future (read hundreds of years).
Pragmatically, it is likely that we will see, in our lifetimes, deprecation of some of the more esoteric usages of English in common conversation (whom is all but gone from most people's vocabularies for instance).