I guess this points out a fundamental problem with case law: it assumes that judges are competent, not corrupt, and have the interest of the populace at heart. This judge doesn't seem to satisfy at least two of those properties.
As an example, Miller described a scenario where a consumer might hook a playback device into the input ports of a recorder. "Those inputs and outputs serve a purpose, but they might not know that they're creating an illegal act," Miller said.
They are? In what way? If I record something on Hi-8 and later want it on VHS, I can do that, and I have paid for it. I have paid for it with the fees I paid for blank media.
The question we should be asking is the legality of asserting copyrights on content that cannot be copied and can never fall into the public domain; technological restrictions on copying and copyright ought to be mutually exclusive.
In Singularity, class loaders are essentially [i]verboten[/i], reflection is compile-time, and garbage collection isn't what you're used to either.
That's all be true, but it doesn't contradict what I said.
In fact, they do a pretty good job of proving you wrong on just about every point you made in the previous thread, so maybe you shouldn't be trying to cite their experience as support for your still-broken ideas about OS design.
I used Singularity only to illustrate one point, namely that fault isolation using a safe language with a well-designed type system is a direction we should be going into, as opposed to using an unsafe language with or without memory management hardware.
You are right that, beyond that, the developers of Singularity have some architectural ideas similar to those in Eros and I consider those aspects of the systems to be equally spurious and unproven. Of course, from your postings, it is evident that your emphasis is the opposite: you view the specific fault isolation mechanism as an unimportant implementation detail and think that the architectural ideas are what matters.
And the fact that you think that a tech report about a half-finished implementation constitutes "proof" of any form illustrates a fundamental problem with operating systems architecture research: it's still all a bunch of handwaving. But until OS researchers get their act together methodologically, at least they should develop the kernels with safer languages and runtimes so that the rest of us can get our work done better. The architectural gimmicks you add, we can easily ignore, like we have for the last half century.
Come on, think about it--when I want to record my home movies, they're going to require that I only have a DRMed, digital copy?
They don't care about home movies. Their vision of the future is that there shall be no devices that permit this. Now, if you hack your device to permit this for home recording, nobody is going to go after you.
But should someone actually publish content that doesn't use the expensive, heavily patented, and ever-changing DRM systems, then they'll go after them. And that's easy to enforce because non-DRM'ed content that becomes popular, well, is widely visible by its very nature.
All this copyright infringement and P2P stuff is a smokescreen--they are afraid of free and open content because it's going to kill their business, and they know it.
What makes you think the interoperability provisions are going to stand?
These people are after total control of speech and content: they want to make the cost of entry into publishing and media so high that only corporations can afford it, the way it used to be in the 20th century. It's comfortable for the media companies and it's comfortable for politicians. And the people that managed to bring you the Sonny Bono copyright extension act, software patents, and now storyline patents, will manage to do just that.
This isn't about retaping stuff or switching to digital. They are scared, not of copyright infringement, but of people being able to create content that's going to replace their on equipment that costs a few hundred bucks. The media, publishing, and entertainment industries are in trouble because all the stuff that is cheap to produce has become so cheap to produce that anybody can do it, leaving only the expensive and high risk ventures. It's the same thing that killed the dinosaurs of the computer industry.
but the above statement is trivially falsifiable. Singularity is built on a microkernel. EROS is built on a microkernel. Anything that can be built on Singularity, can be built on EROS, including verifiers, virtual machines, Software Isolated Processes, etc.
Whether or not you call the two systems "microkernels", they are different designs and use very different runtimes. You can implement the same architectural features in both, but that's like saying that you can implement anything in assembly that you can implement in Perl--it's just not an interesting statement.
EROS has a default mechanism for isolating faults and loading untrusted code in the absence of any safety guarantees: the constructor.
And you do a context switch on every method call? C# and Java guarantee fault isolation at the level of the individual programming language object, there is nothing like it in any C-based system. C# and Java also allow you to get information about the type and structure of every single allocated block of storage; try that in a C runtime.
Not that you know what developing on an EROS-like system is like, considering it's a completely revolutionary architecture comparable only to KeyKOS from which it's derived.
The architecture isn't at issue, at issue is developing kernel modules in an unsafe language without reflection, without class loaders, and without garbage collection.
Garbage collection in the kernel is a stupid idea. Whenever you make a garbage collector implementation, it's tailored to a specific language, and a specific usage pattern.
Even if those statements weren't utter nonsense, I suggest you enumerate the languages that I can currently write kernel code in. Well, let's see: C, and...? Oh, there is nothing else. What about a CLR-based kernel? Wow, I can write kernel modules in C, C++, Java, C#, Basic, Oberon, Eiffel, F#, OCAML, Prolog, Smalltalk, Python, and probably a lot more.
Of course, user mode software can be written in any language.
Putting a GC in the kernel forces the same policy-decisions onto everyone, and I fail to see any benefit in that!
A kernel GC only collects kernel data structures, more efficiently and reliably than anything you could do by hand. But if you like, you can still adopt whatever inefficient manual policies you want to implement, both for kernel and for user code.
This basically is a description of the click wheel
No, it's not. The iPod does scanning and skipping via left and right clicks, but you must use the wheel for volume control. Directional pads use up-down for volume. The center button would make a great start/stop.
Worse, you can't avoid using the wheel for navigating the menus. The interaction between menus, the wheel, and the buttons is quite unintuitive. Other players solve the problem of switching between navigating and playing a lot more simply.
only it's more powerful because you can either scan by holding or scan by rotating.
You can't scan by rotating; you have to go into the scan mode and then rotate. When you just touch the thing, you'll change the volume (which frequently happens accidentally).
You know, looking at your post again, I don't even think you have an iPod with a click wheel:
You know, looking at your post again, it's clear you are just the typical Apple fanboy who knows nothing about other systems but thinks that anything that is shiny and bright and has an Apple logo on it must be by default usable.
Again, the iPods are not bad; but they are certainly not the beacon of usability people like you make them out to be. Mostly, the reason to buy them is because they look nice, they work OK, and they integrate well with iTunes.
EROS uses C and relies on memory management hardware for isolation. EROS also can't analyze or verify code it loads.
Singularity uses C# and does not use memory management hardware for protection; it guarantees isolation via runtime checks, and it can perform extensive code analysis on load.
I don't know whether Singularity is going to make it, but I have used and developed on systems like it (the idea isn't new), and it is a lot nicer than either UNIX kernels or EROS-like kernels.
It's good that, after a 20 year hiatus, people are starting to write operating systems in languages again that are a bit saner than C.
While not new, maybe this will spur on others to start similar efforts. We really need a successor to Linux and BSD, something with runtime safety and garbage collection in the kernel.
Behind all this rhetoric is actually the opposite of what Barr and Schroeder say. They are not afraid of Google scanning their content; the opt-out provision is trivial for big publishers to deal with. If Houghton-Mifflin doesn't want any of its books scanned, a single letter suffices.
No, what they are afraid of is that with an opt-out policy, Google will pick up lots of content that they don't control and that provides cheap or free alternatives to what they sell at inflated prices. They rightfully fear for the businesses they represent, they just fear for it not because of copyright violations, but because of all the competition that actually exists but that is still hard to find at this point.
The kind of transparent rhetoric that these Washington has-beens are using, like referring to Google's search index as a "free online library" and to Google's quite defensible fair use arguments as a "license to steal", is almost amusing at this point. That kind of talk only reveals that much more clearly how political and out of touch these people are. Fortunately, their efforts are ultimately for nothing: CNN and big publishing houses will hit their trees, too, no matter what rhetorical or political stunts their hired help tries to pull.
I'm not sure where you're from, but the way it works in the US (roughly) is that laws set down general rules, and its application to new situations is governed by courts. Courts thereby create a body of precendents that function similar to laws. If legislators don't like what the courts are doing with a law, then they go back and change or amend the law.
The first part of this statement doesn't give you any more credibility or validity
But it does give me a basis for comparison.
and the second part is completely subjective
Quite to the contrary: usability is not just subjective, it is measurable: how long does it take users to accomplish tasks, how much training do they require, etc.
The click wheel is IMO very usable and superior to any interface I've yet come across
Well, and IMO, it's worse, so there. Until someone does a usability test, we'll just have to leave it at that.
and I think based on sales figures a lot of people agree with that assessment
Yeah, because, as we all know, sales figures tell you exactly how good a product is, right? So, in your opinion, the Windows interface must then be much better than the Macintosh interface because Windows outsells Macintosh 50:1, right? Or do sales figures only come into play when they confirm your prejudices?
Yes, and unwanted pregnancies greatly contribute to poverty, for a variety of reasons. Hence, reducing unwanted pregnancies reduces hunger.
But it is false for you to conclude that overpopulation isn't also responsible for hunger. There may be enough food in existence in theory to feed the world, but obviously, we don't manage to distribute it efficiently. There is no reason to believe that we'll solve that problem. Lower population densities and numbers mean we need to distribute food less efficiently, and that local production may be sufficient to support local populations.
a scrollwheel allows you to control the scrolling with barely a touch
It doesn't work that way. Precise motor control requires a certain amount of force, and if the controller doesn't provide a counterforce, your own muscle have to, which makes things worse. You're better off using friction, but on the clickwheel you can't do that because then you click.
is that you don't have to hurt your thumb holding down or clicking on a tiny button
The button doesn't have to be tiny, it can be a big, smooth, comfortable directional pad. In fact, I think the iPod interface would be better if they dropped the touch sensitivity altogether and otherwise kept the click part of the click-wheel and programmed it more intelligently. For an added bonus, they could make the click wheel pressure sensitive.
I think there should be a law that no patent can be enforced against users of a standard, if the patent holder proposed adding infringing features to that standard without (a) making it clear their proposal includes patented technology and (b) announcing their intention to charge license fees for their technology. In that case, I'd be wholeheartedly behind mono.
That's what standards bodies like ECMA and ISO are for--they require specific procedures and disclosures when it comes to patents. Microsoft went through this, so we know they are committed to being compliant with ECMA and ISO regulations when it comes to patents and intellectual property. Sun chickened out when faced with this--they withdrew their standards body submissions over ECMA, ANSI, and ISO's requirements for disclosure and openness.
But I still worry about the possiblity of some of the technology being covered, either under a submarine patent (although I suppose at this late date this is extremely unlikely), or under a published patent where the applicability to the C# technology is not obvious to anybody but some devious Microsoft strategist. It may border on the paranoid now, but I can't help it. I know Microsoft is a brutal competitor, and I don't think they're beyond doing such a thing if they can get away with it.
The fact that there is a connection between Mono and Microsoft, however slight, doesn't make me happy either. But, in the end, what's the worst that's going to happen?
First of all, Microsoft can't claim willful infringement if people don't know about the patent, so there wouldn't be any penalties. And what damages are they going to claim? And damages are usually based on revenue, but who derives revenue from shipping Mono commercially?
If Microsoft were to assert a patent claim, people would work around it within a few weeks and the matter would be closed; it is implausible that any judge would even waste time looking at the matter after that.
Also, FOSS must be violating lots of Microsoft patents, at least on paper: the Linux kernel, Apache, Mozilla, etc. From a purely practical point of view, Microsoft must have done the calculation and decided that it simply isn't worth doing anything about it..NET is an unlikely place for them to start sueing. If they wanted to hurt FOSS, they'd go after the Linux kernel or Apache.
There are several so-called FOSS supporters that have licenses and intellectual property that constitutes a much bigger risk to the FOSS community than anything Microsoft has. Microsoft and Mono just isn't high on my list of worries.
Maemo looks great, both technically and the way they are going about setting it up. I particularly like the fact that they have built their environment on top of X11, which means that it will be much easier to port custom software to it than with Qt/Embedded devices.
Python for the S60 is nice, too, of course.
Altogether, I'm wondering whether Nokia is planning on moving their entire phone line over to Linux at some point.
That clickwheel interface is pretty amazing--I haven't used such an intuitive device interface in a long time.
I have about a dozen MP3 players, and the clickwheel is not very good: it's too hard to control precisely and it's modal.
It's the boring, mainstream MP3 players that are intuitive. Simple designs have separate buttons for play, pause, skip left/right, scan left/right, and volume up/down. And the directional pad, which has push to play/pause, up/down for volume, push left/right to skip, and hold left/right to scan, is probably the best of the controls: it's simple, it's tiny, and it's intuitive. The clickwheel doesn't even come close.
The clickwheel is great branding, but only tolerable usability.
iPods are decent enough MP3 players, but they aren't winning in the market because of technology or functionality, they're winning because of distinctive branding and good industrial design.
I'll probably buy a Neuros if it's hackable. But I don't think this box is going to take the world by storm. I think what might is if one of the 2G or 4G gumstick flash players became hackable and programmble; there are some neat things one might be able to do with them, in particular if they also got some additional, interesting I/O ports (Bluetooth, IrDA,...).
I'm seriously amazed at how stupid some people could be adopting Microsoft's technology instead of leveraging other open source technologies.
The combination of ECMA C# and Gtk# is 100% open source technologies, and that is what open source applications are built on.
You don't have to worry about the Microsoft aspects of C#--those are part of Novell's business plan. I'm sure their lawyers have done their homework and weighed the risks. But even if they got it wrong, it has no influence on the open source parts of Mono.
Novell didn't "trip over its Linux strategy". Novell's primary product, Netware, was dead when Microsoft finally incorporated equivalent functionality into Windows. That's what the company "tripped over". Novell was essentially dead before they started doing anything with Linux. I find it amazing that they have managed to stay so relevant and important, and their acquisitions of SuSE and their support of Mono look like excellent ideas.
There is no way that their move into Linux was ever going to keep them going at their past levels. That's neither surprising, nor is it Linux's fault. You can make a decent business out of FOSS, but it's not going to be a cash cow like Windows or the old Novell.
I frankly can't judge whether Novell is executing right with SuSE. But the quality of SuSE as a distribution has been consistently high, and they have a good shot at selling to businesses, in particular in the European markets. I hope they'll make it, alongside RedHat and a completely free Debian; we need more and smaller companies, not a few behemoths. And, to me, the Linux distributions strike a good balance between compatibility and diversity.
Slashdot Mirror
I guess this points out a fundamental problem with case law: it assumes that judges are competent, not corrupt, and have the interest of the populace at heart. This judge doesn't seem to satisfy at least two of those properties.
As an example, Miller described a scenario where a consumer might hook a playback device into the input ports of a recorder. "Those inputs and outputs serve a purpose, but they might not know that they're creating an illegal act," Miller said.
They are? In what way? If I record something on Hi-8 and later want it on VHS, I can do that, and I have paid for it. I have paid for it with the fees I paid for blank media.
The question we should be asking is the legality of asserting copyrights on content that cannot be copied and can never fall into the public domain; technological restrictions on copying and copyright ought to be mutually exclusive.
In Singularity, class loaders are essentially [i]verboten[/i], reflection is compile-time, and garbage collection isn't what you're used to either.
That's all be true, but it doesn't contradict what I said.
In fact, they do a pretty good job of proving you wrong on just about every point you made in the previous thread, so maybe you shouldn't be trying to cite their experience as support for your still-broken ideas about OS design.
I used Singularity only to illustrate one point, namely that fault isolation using a safe language with a well-designed type system is a direction we should be going into, as opposed to using an unsafe language with or without memory management hardware.
You are right that, beyond that, the developers of Singularity have some architectural ideas similar to those in Eros and I consider those aspects of the systems to be equally spurious and unproven. Of course, from your postings, it is evident that your emphasis is the opposite: you view the specific fault isolation mechanism as an unimportant implementation detail and think that the architectural ideas are what matters.
And the fact that you think that a tech report about a half-finished implementation constitutes "proof" of any form illustrates a fundamental problem with operating systems architecture research: it's still all a bunch of handwaving. But until OS researchers get their act together methodologically, at least they should develop the kernels with safer languages and runtimes so that the rest of us can get our work done better. The architectural gimmicks you add, we can easily ignore, like we have for the last half century.
Come on, think about it--when I want to record my home movies, they're going to require that I only have a DRMed, digital copy?
They don't care about home movies. Their vision of the future is that there shall be no devices that permit this. Now, if you hack your device to permit this for home recording, nobody is going to go after you.
But should someone actually publish content that doesn't use the expensive, heavily patented, and ever-changing DRM systems, then they'll go after them. And that's easy to enforce because non-DRM'ed content that becomes popular, well, is widely visible by its very nature.
All this copyright infringement and P2P stuff is a smokescreen--they are afraid of free and open content because it's going to kill their business, and they know it.
What makes you think the interoperability provisions are going to stand?
These people are after total control of speech and content: they want to make the cost of entry into publishing and media so high that only corporations can afford it, the way it used to be in the 20th century. It's comfortable for the media companies and it's comfortable for politicians. And the people that managed to bring you the Sonny Bono copyright extension act, software patents, and now storyline patents, will manage to do just that.
This isn't about retaping stuff or switching to digital. They are scared, not of copyright infringement, but of people being able to create content that's going to replace their on equipment that costs a few hundred bucks. The media, publishing, and entertainment industries are in trouble because all the stuff that is cheap to produce has become so cheap to produce that anybody can do it, leaving only the expensive and high risk ventures. It's the same thing that killed the dinosaurs of the computer industry.
but the above statement is trivially falsifiable. Singularity is built on a microkernel. EROS is built on a microkernel. Anything that can be built on Singularity, can be built on EROS, including verifiers, virtual machines, Software Isolated Processes, etc.
Whether or not you call the two systems "microkernels", they are different designs and use very different runtimes. You can implement the same architectural features in both, but that's like saying that you can implement anything in assembly that you can implement in Perl--it's just not an interesting statement.
EROS has a default mechanism for isolating faults and loading untrusted code in the absence of any safety guarantees: the constructor.
And you do a context switch on every method call? C# and Java guarantee fault isolation at the level of the individual programming language object, there is nothing like it in any C-based system. C# and Java also allow you to get information about the type and structure of every single allocated block of storage; try that in a C runtime.
Not that you know what developing on an EROS-like system is like, considering it's a completely revolutionary architecture comparable only to KeyKOS from which it's derived.
The architecture isn't at issue, at issue is developing kernel modules in an unsafe language without reflection, without class loaders, and without garbage collection.
Garbage collection in the kernel is a stupid idea. Whenever you make a garbage collector implementation, it's tailored to a specific language, and a specific usage pattern.
...? Oh, there is nothing else. What about a CLR-based kernel? Wow, I can write kernel modules in C, C++, Java, C#, Basic, Oberon, Eiffel, F#, OCAML, Prolog, Smalltalk, Python, and probably a lot more.
Even if those statements weren't utter nonsense, I suggest you enumerate the languages that I can currently write kernel code in. Well, let's see: C, and
Of course, user mode software can be written in any language.
Putting a GC in the kernel forces the same policy-decisions onto everyone, and I fail to see any benefit in that!
A kernel GC only collects kernel data structures, more efficiently and reliably than anything you could do by hand. But if you like, you can still adopt whatever inefficient manual policies you want to implement, both for kernel and for user code.
This basically is a description of the click wheel
No, it's not. The iPod does scanning and skipping via left and right clicks, but you must use the wheel for volume control. Directional pads use up-down for volume. The center button would make a great start/stop.
Worse, you can't avoid using the wheel for navigating the menus. The interaction between menus, the wheel, and the buttons is quite unintuitive. Other players solve the problem of switching between navigating and playing a lot more simply.
only it's more powerful because you can either scan by holding or scan by rotating.
You can't scan by rotating; you have to go into the scan mode and then rotate. When you just touch the thing, you'll change the volume (which frequently happens accidentally).
You know, looking at your post again, I don't even think you have an iPod with a click wheel:
You know, looking at your post again, it's clear you are just the typical Apple fanboy who knows nothing about other systems but thinks that anything that is shiny and bright and has an Apple logo on it must be by default usable.
Again, the iPods are not bad; but they are certainly not the beacon of usability people like you make them out to be. Mostly, the reason to buy them is because they look nice, they work OK, and they integrate well with iTunes.
The two are very different beasts.
EROS uses C and relies on memory management hardware for isolation. EROS also can't analyze or verify code it loads.
Singularity uses C# and does not use memory management hardware for protection; it guarantees isolation via runtime checks, and it can perform extensive code analysis on load.
I don't know whether Singularity is going to make it, but I have used and developed on systems like it (the idea isn't new), and it is a lot nicer than either UNIX kernels or EROS-like kernels.
It's good that, after a 20 year hiatus, people are starting to write operating systems in languages again that are a bit saner than C.
While not new, maybe this will spur on others to start similar efforts. We really need a successor to Linux and BSD, something with runtime safety and garbage collection in the kernel.
Behind all this rhetoric is actually the opposite of what Barr and Schroeder say. They are not afraid of Google scanning their content; the opt-out provision is trivial for big publishers to deal with. If Houghton-Mifflin doesn't want any of its books scanned, a single letter suffices.
No, what they are afraid of is that with an opt-out policy, Google will pick up lots of content that they don't control and that provides cheap or free alternatives to what they sell at inflated prices. They rightfully fear for the businesses they represent, they just fear for it not because of copyright violations, but because of all the competition that actually exists but that is still hard to find at this point.
The kind of transparent rhetoric that these Washington has-beens are using, like referring to Google's search index as a "free online library" and to Google's quite defensible fair use arguments as a "license to steal", is almost amusing at this point. That kind of talk only reveals that much more clearly how political and out of touch these people are. Fortunately, their efforts are ultimately for nothing: CNN and big publishing houses will hit their trees, too, no matter what rhetorical or political stunts their hired help tries to pull.
I'm not sure where you're from, but the way it works in the US (roughly) is that laws set down general rules, and its application to new situations is governed by courts. Courts thereby create a body of precendents that function similar to laws. If legislators don't like what the courts are doing with a law, then they go back and change or amend the law.
The first part of this statement doesn't give you any more credibility or validity
But it does give me a basis for comparison.
and the second part is completely subjective
Quite to the contrary: usability is not just subjective, it is measurable: how long does it take users to accomplish tasks, how much training do they require, etc.
The click wheel is IMO very usable and superior to any interface I've yet come across
Well, and IMO, it's worse, so there. Until someone does a usability test, we'll just have to leave it at that.
and I think based on sales figures a lot of people agree with that assessment
Yeah, because, as we all know, sales figures tell you exactly how good a product is, right? So, in your opinion, the Windows interface must then be much better than the Macintosh interface because Windows outsells Macintosh 50:1, right? Or do sales figures only come into play when they confirm your prejudices?
Poverty causes hunger
Yes, and unwanted pregnancies greatly contribute to poverty, for a variety of reasons. Hence, reducing unwanted pregnancies reduces hunger.
But it is false for you to conclude that overpopulation isn't also responsible for hunger. There may be enough food in existence in theory to feed the world, but obviously, we don't manage to distribute it efficiently. There is no reason to believe that we'll solve that problem. Lower population densities and numbers mean we need to distribute food less efficiently, and that local production may be sufficient to support local populations.
a scrollwheel allows you to control the scrolling with barely a touch
It doesn't work that way. Precise motor control requires a certain amount of force, and if the controller doesn't provide a counterforce, your own muscle have to, which makes things worse. You're better off using friction, but on the clickwheel you can't do that because then you click.
is that you don't have to hurt your thumb holding down or clicking on a tiny button
The button doesn't have to be tiny, it can be a big, smooth, comfortable directional pad. In fact, I think the iPod interface would be better if they dropped the touch sensitivity altogether and otherwise kept the click part of the click-wheel and programmed it more intelligently. For an added bonus, they could make the click wheel pressure sensitive.
I think there should be a law that no patent can be enforced against users of a standard, if the patent holder proposed adding infringing features to that standard without (a) making it clear their proposal includes patented technology and (b) announcing their intention to charge license fees for their technology. In that case, I'd be wholeheartedly behind mono.
.NET is an unlikely place for them to start sueing. If they wanted to hurt FOSS, they'd go after the Linux kernel or Apache.
That's what standards bodies like ECMA and ISO are for--they require specific procedures and disclosures when it comes to patents. Microsoft went through this, so we know they are committed to being compliant with ECMA and ISO regulations when it comes to patents and intellectual property. Sun chickened out when faced with this--they withdrew their standards body submissions over ECMA, ANSI, and ISO's requirements for disclosure and openness.
But I still worry about the possiblity of some of the technology being covered, either under a submarine patent (although I suppose at this late date this is extremely unlikely), or under a published patent where the applicability to the C# technology is not obvious to anybody but some devious Microsoft strategist. It may border on the paranoid now, but I can't help it. I know Microsoft is a brutal competitor, and I don't think they're beyond doing such a thing if they can get away with it.
The fact that there is a connection between Mono and Microsoft, however slight, doesn't make me happy either. But, in the end, what's the worst that's going to happen?
First of all, Microsoft can't claim willful infringement if people don't know about the patent, so there wouldn't be any penalties. And what damages are they going to claim? And damages are usually based on revenue, but who derives revenue from shipping Mono commercially?
If Microsoft were to assert a patent claim, people would work around it within a few weeks and the matter would be closed; it is implausible that any judge would even waste time looking at the matter after that.
Also, FOSS must be violating lots of Microsoft patents, at least on paper: the Linux kernel, Apache, Mozilla, etc. From a purely practical point of view, Microsoft must have done the calculation and decided that it simply isn't worth doing anything about it.
There are several so-called FOSS supporters that have licenses and intellectual property that constitutes a much bigger risk to the FOSS community than anything Microsoft has. Microsoft and Mono just isn't high on my list of worries.
Maemo looks great, both technically and the way they are going about setting it up. I particularly like the fact that they have built their environment on top of X11, which means that it will be much easier to port custom software to it than with Qt/Embedded devices.
Python for the S60 is nice, too, of course.
Altogether, I'm wondering whether Nokia is planning on moving their entire phone line over to Linux at some point.
I much prefer this to one of those many-microscopic-button dealies...
The neat thing is that you only need one button to control a player, a kind of D-PAD:
push to start/stop
up-down for volume
left-right for skip
left-right hold for scan
The players use a separate button to switch to menu mode, where the thing functions in the obvious way (for way navigation, push to select).
Doesn't require a manual either, since it's easy to label the functions.
There are several no-name brands that use this. I think it's the best UI: unassuming, simple, and makes good use of space.
The iPod clickwheel is great as a brand statement, but as a controller, I think it's far from the best.
That clickwheel interface is pretty amazing--I haven't used such an intuitive device interface in a long time.
I have about a dozen MP3 players, and the clickwheel is not very good: it's too hard to control precisely and it's modal.
It's the boring, mainstream MP3 players that are intuitive. Simple designs have separate buttons for play, pause, skip left/right, scan left/right, and volume up/down. And the directional pad, which has push to play/pause, up/down for volume, push left/right to skip, and hold left/right to scan, is probably the best of the controls: it's simple, it's tiny, and it's intuitive. The clickwheel doesn't even come close.
The clickwheel is great branding, but only tolerable usability.
iPods are decent enough MP3 players, but they aren't winning in the market because of technology or functionality, they're winning because of distinctive branding and good industrial design.
...).
I'll probably buy a Neuros if it's hackable. But I don't think this box is going to take the world by storm. I think what might is if one of the 2G or 4G gumstick flash players became hackable and programmble; there are some neat things one might be able to do with them, in particular if they also got some additional, interesting I/O ports (Bluetooth, IrDA,
Just to clarify: the Mono .NET implementation is, of course, also open source. But it's an open source implementation of proprietary APIs.
By "the open source parts of Mono", I was referring to open source implementations of open and free APIs: ECMA C# and Gtk+.
I'm seriously amazed at how stupid some people could be adopting Microsoft's technology instead of leveraging other open source technologies.
The combination of ECMA C# and Gtk# is 100% open source technologies, and that is what open source applications are built on.
You don't have to worry about the Microsoft aspects of C#--those are part of Novell's business plan. I'm sure their lawyers have done their homework and weighed the risks. But even if they got it wrong, it has no influence on the open source parts of Mono.
Novell didn't "trip over its Linux strategy". Novell's primary product, Netware, was dead when Microsoft finally incorporated equivalent functionality into Windows. That's what the company "tripped over". Novell was essentially dead before they started doing anything with Linux. I find it amazing that they have managed to stay so relevant and important, and their acquisitions of SuSE and their support of Mono look like excellent ideas.
There is no way that their move into Linux was ever going to keep them going at their past levels. That's neither surprising, nor is it Linux's fault. You can make a decent business out of FOSS, but it's not going to be a cash cow like Windows or the old Novell.
I frankly can't judge whether Novell is executing right with SuSE. But the quality of SuSE as a distribution has been consistently high, and they have a good shot at selling to businesses, in particular in the European markets. I hope they'll make it, alongside RedHat and a completely free Debian; we need more and smaller companies, not a few behemoths. And, to me, the Linux distributions strike a good balance between compatibility and diversity.
Actuall, we programmers try to think of it as "allocation", "freeing", and "releasing". So, no, they haven't been "fired", they have been "freed".