I would presume that a fork would be do to more than just change the licensing, just like the XFree86 fork resulted in major changes. Remember when Linus ripped out the VM in Linux 2.4, which was a so-called stable series? IIRC, his justification for making major changes to stable releases was that he'd get more testers that way. Which is nice... using your credibility to get a bunch of people to unwittingly test your beta-quality software on production systems!
Not to mention that Linus doesn't seem to be making any effort toward stabilizing the kernel and tackling long-term security issues by reducing the complexity of the code that runs in ring-0. I'm not necessarily advocating a full-blown microkernel (though L4-based systems do look promising), but it would be nice if we could have some confidence that there aren't locally-exploitable root holes in the kernel. At present, it looks like Linux is just going to keep getting bigger without any attention paid to the implications of running more and more code in a privileges domain.
Nobody is going to successfully fork Linux solely over GPLv3, but IMHO Linux needs better management anyway, and GPLv3 might act as a good "sync pulse" for getting a fork started.
Has any of these developers actually consulted with a good IPR lawyer before making these statements? They continue to bitch about the restrictions on "encryption", but I just don't see it, and neither does PJ of Groklaw.
5.2 Additional Restrictions Clause
They sort of have a point, but on the other hand, I think it would help greatly if GPL programs could implicitly link with OpenSSL, for example.
5.3 Patents Provisions
Personally, I like this clause. Of course, the problems would go away if software patents did too.
License proliferation
I think this line is rich:
In deference to the critical role of distributions, we regard reducing the Open Source licensing profusion as a primary objective.
<sarcasm>Sure guys, that's why you switched to GPLv2-only licensing: to reduce licensing profusion.</sarcasm>
The BSD license also makes it nearly impossible to compete against proprietary software, since the proprietary software can always incorporate your improvements, but you can't incorporate its improvements.
Of course, people who licence stuff under the BSDL don't care about that (which is why they do so).
The claims I'm referring to are his claims that old versions of Linux were GPLv2 only, when in fact they were a mix of GPLv2-or-later, GPLv2-only, and *any* version of the GPL (due to GPLv2 section 9). Linus likes to ignore section 9 when he says that, e.g. the old build system are covered by GPLv2-only.
I should clarify that this is for the position statement, not the poll.
Frankly, I think the FSF should go ahead without them. Linux kernel developers have always been shortsighted when it comes to freedom. Those of us who care will probably fork Linux (which *can* be done, dispite Linus' incorrect claims to the contrary). It's going to have to be done sooner or later anyway.
I can't see why AOL would pull the premiere, except so that they (AOL Time-Warner, remember?) can later claim that Internet piracy is causing them problems.
Ingo Molnar (and others) have been designing Linux to be real-time for many years now. And Novell has elaborated on that work, to provide a packaged system with a large supporting enterprise, which system is specifically designed to be capable of hard real-time operation.
Hard realtime and safety-critical are two completely different things, althougth the latter may require the former.
Would you rather trust a closed-source product with 10 engineers reviewing the code, or an open-source one with 10,000 engineers reviewing the code, among them, quite possibly, several of your own hires? Would you rather trust a system that has been deployed in 100 designs, or one deployed in 100,000 designs?
Being open-source has absolutely nothing to do with my argument. In safety-critical systems, you want the entire operation of the system to be predictable. That means you might not want preemptive multitasking/multithreading, virtual memory, or really most of what POSIX offers.
I seriously doubt that "10,000 engineers" are reviewing "100,000 designs" that use Linux as stripped-down as it would need to be to really be appropriate for safety-critical systems. (I doubt that there are even 500 professional engineers who are qualified to work with safety-critical computer systems working on Linux at all, never mind 20 times that number.)
Linux is simply too complex for safety-critical systems where nearly any bugs are unacceptable. Heck, Linux hasn't even got locally-exploitable security bugs under control, never mind other kinds of bugs. Furthermore, Linux pretty much requires gcc, and gcc has bugs.
The primary advantage of embedded Linux is reduced non-recurring engineering costs, because it can do a whole bunch of things out-of-the-box that other more specialized systems can't. That's great for most cases, where occasional errors are acceptable, but it's that flexibility (resulting from Linux's complexity) that makes it inappropriate in safety-critical systems.
I haven't really used QNX or VxWorks, so I can't comment on those, but my understanding is that they're quite a bit simpler than Linux, which is a major benefit for this application. My suggestion (if you need a generic multitasking OS at all) would probably be something small like L4, with a few very well-defined tasks passing messages between each other. If you need to use Linux, run it on a separate machine that communicates with the safety-critical systems, but is not safety-critical itself.
What the hell? Didn't we learn like 20 years ago that in-band signalling is a security nightmare? Why was this guy able to reprogram the ATM without opening up the case?
No it's not like that at all. It's not like anything, except the plain statement that patents, designed for finite, physical objects, should not be applied to infinitely reproducible items like software.
It not anything nearly that general. Or, at least, we don't know that it is. What we know is that we've tried applying patents to software, and over the last few decades, it's proven to be detrimental.
Personally, I think you should be able to file a patent on nearly any invention, but patents should be enforced in different ways, depending on how the technology is being used. If you're suing over the technology being used in software, you get nothing, or maybe enforcement for 2 years, tops. If it's in an ASIC, maybe 5 years. Pharmaceuticals, 20 years (or whatever). This would all be for the same patent, but you get monopoly power over various sectors of the economy for different times (and under different terms). Ongoing monitoring would result in regulatory changes, as necessary to promote progress.
Measures like this give they appearence that something has been fixed.
Indeed. Look at crypto export regulations. A lot of people now think that cryptography isn't meaningfully regulated, but in reality, only mass-market software is free from the onerous restrictions. If you start selling, say, a secure wireless keyboard over the Internet, you can still be charged with a crime. (Why do you think there are *still* no actually-secure wireless keyboards on the market?)
The only way for Microsoft to defeat that would be to withdraw support for all the "real" sound cards that it emulates. That would probably leave them open to prosecution.
Or they could "innovate" a new bus architecture, which happens to have HDMI or something built-in, and finally drop support for PCI and ISA.
Let's see. Symantec's business model is selling products that work around Windows's brokenness. Now Microsoft is trying to fix Windows (though I doubt they'll be successful), and so Symantec is whining.
Adobe made and advertised PDF as an open standard. Now they're complaining that the standard is being implemented.
Personally, I'd enjoy seeing Microsoft barred from providing security fixes and PDF support, but that's just because I think Windows is already a hopeless shipwreck that will benefit the world by quickly reaching the end of its life. =)
Seriously, though, I'm not actually sure that Microsoft should be able to enter all these markets. The company should have been split up in 1999.
I found one case where the whitespace was a hindrance, and it was only because I was trying to use Python directly as a templating language, which is dumb anyway. Even then, it still worked.
This was the problem: I effectively had code that did this:
if ([condition]) { [bunch of lines of HTML] } else { [bunch of more lines of HTML] }
I was worried about the trailing brace, which in Python, was supposed to be either a line of code, or a comment character, indented at the appropriate location. Even in another language, it was a stupid design. It's hard to match a single closing brace in the middle of nowhere with its corresponding opening brace, unless you have a good editor, which you have already said won't be the case. In Python it was slightly worse, because you'd end up with comment characters that had a particular significance, but it's not like I should have been doing that anyway.
Let's recap: the "whitespace issue" has just never been a serious problem, and has been quite helpful for when I've had to debug other people's code. You, so far, haven't convinced me that it can be a real problem, because you haven't given me any real examples of where Python was the wrong choice of language due to the way it handles whitespace. I repeat: The whitespace issue itself has never been a serious enough problem to render Python less suitable than some other language for any job I've worked on, and it has sometimes been beneficial..
So far, the only thing you have established (well, I was the one to establish it) is that control structures based on whitespace are, in at least one case, suboptimal. That's a far cry from your generalization:
control structures based on whitespace are stupid
On the plus side, you haven't called me homosexual or a Nazi or something like that yet, which is quite a surprise, given that this is Slashdot.:)
So you're saying that programming languages should be designed around Microsoft Word? And for the record, I see no reason why you couldn't edit Python code using MS Word. Even if you couldn't, you could just install gvim for Win32 or just dump it into a folder and run it from there (if you don't have admin access to the machine), or use Notepad, or whatever.
You're grasping at straws. So far, you've given me all sorts of reasons why whitespace significance could hypothetically be a problem, but no examples of how it actually is a meaningful problem in real life. I cringed at the thought of Python's whitespace significance when I first used it. I got over it in about a week, because it just isn't a problem.
I have found exactly one scenario where the whitespace handling is a problem: in mod_python Python Server Pages (basically inline-able Python code, like you can do with PHP). Even there, it worked, but I just didn't trust it to be maintainable. On the other hand, most people consider inlining code that way to be bad practice anyway. Furthermore, if you use the more elaborate Spyce intead of mod_python's built-in methanism, you can use braces around blocks anyway.
The bottom line is that I've been using Python, often in a professional capacity, for about 5 years, and the "whitespace issue" has just never been a serious problem, and has been quite helpful for when I've had to debug other people's code. You, so far, haven't convinced me that it can be a real problem, because you haven't given me any real examples of where Python was the wrong choice of language due to the way it handles whitespace.
Like what editor? Even if your editor converts tabs to spaces or something, Python's parser can handle that just fine. All it does it look at the indentation of the current line relative to the indentation of previous lines.
If you're using an editor that mangles whitespace to such an extent that Python's parser can't handle it, and then submitting the results to some source code repository, you're creating a maintenance headache anyway.
Unless you're going to provide specific examples, it sounds more like a problem of your using a chisel as a screwdriver than a legitimate problem with the language.
Slashdot Mirror
Are you implying that the F/OSS movement is communist? That's been debunked to death already.
I would presume that a fork would be do to more than just change the licensing, just like the XFree86 fork resulted in major changes. Remember when Linus ripped out the VM in Linux 2.4, which was a so-called stable series? IIRC, his justification for making major changes to stable releases was that he'd get more testers that way. Which is nice... using your credibility to get a bunch of people to unwittingly test your beta-quality software on production systems!
Not to mention that Linus doesn't seem to be making any effort toward stabilizing the kernel and tackling long-term security issues by reducing the complexity of the code that runs in ring-0. I'm not necessarily advocating a full-blown microkernel (though L4-based systems do look promising), but it would be nice if we could have some confidence that there aren't locally-exploitable root holes in the kernel. At present, it looks like Linux is just going to keep getting bigger without any attention paid to the implications of running more and more code in a privileges domain.
Nobody is going to successfully fork Linux solely over GPLv3, but IMHO Linux needs better management anyway, and GPLv3 might act as a good "sync pulse" for getting a fork started.
It's not quite that bad. Lots of developers are still releasing their code as GPLv2-or-later.
5.1 DRM Clauses
Has any of these developers actually consulted with a good IPR lawyer before making these statements? They continue to bitch about the restrictions on "encryption", but I just don't see it, and neither does PJ of Groklaw.
5.2 Additional Restrictions Clause
They sort of have a point, but on the other hand, I think it would help greatly if GPL programs could implicitly link with OpenSSL, for example.
5.3 Patents Provisions
Personally, I like this clause. Of course, the problems would go away if software patents did too.
License proliferation
I think this line is rich:
<sarcasm>Sure guys, that's why you switched to GPLv2-only licensing: to reduce licensing profusion.</sarcasm>
The BSD license also makes it nearly impossible to compete against proprietary software, since the proprietary software can always incorporate your improvements, but you can't incorporate its improvements.
Of course, people who licence stuff under the BSDL don't care about that (which is why they do so).
Foresight? Why did the FSF include the patents section in GPLv2, even though software patents weren't really a problem in 1991?
Gah. s/dispite/despite/.
The claims I'm referring to are his claims that old versions of Linux were GPLv2 only, when in fact they were a mix of GPLv2-or-later, GPLv2-only, and *any* version of the GPL (due to GPLv2 section 9). Linus likes to ignore section 9 when he says that, e.g. the old build system are covered by GPLv2-only.
I should clarify that this is for the position statement, not the poll.
Frankly, I think the FSF should go ahead without them. Linux kernel developers have always been shortsighted when it comes to freedom. Those of us who care will probably fork Linux (which *can* be done, dispite Linus' incorrect claims to the contrary). It's going to have to be done sooner or later anyway.
Anybody else?
I can't see why AOL would pull the premiere, except so that they (AOL Time-Warner, remember?) can later claim that Internet piracy is causing them problems.
Hard realtime and safety-critical are two completely different things, althougth the latter may require the former.
Being open-source has absolutely nothing to do with my argument. In safety-critical systems, you want the entire operation of the system to be predictable. That means you might not want preemptive multitasking/multithreading, virtual memory, or really most of what POSIX offers.
I seriously doubt that "10,000 engineers" are reviewing "100,000 designs" that use Linux as stripped-down as it would need to be to really be appropriate for safety-critical systems. (I doubt that there are even 500 professional engineers who are qualified to work with safety-critical computer systems working on Linux at all, never mind 20 times that number.)
Linux is simply too complex for safety-critical systems where nearly any bugs are unacceptable. Heck, Linux hasn't even got locally-exploitable security bugs under control, never mind other kinds of bugs. Furthermore, Linux pretty much requires gcc, and gcc has bugs.
The primary advantage of embedded Linux is reduced non-recurring engineering costs, because it can do a whole bunch of things out-of-the-box that other more specialized systems can't. That's great for most cases, where occasional errors are acceptable, but it's that flexibility (resulting from Linux's complexity) that makes it inappropriate in safety-critical systems.
I haven't really used QNX or VxWorks, so I can't comment on those, but my understanding is that they're quite a bit simpler than Linux, which is a major benefit for this application. My suggestion (if you need a generic multitasking OS at all) would probably be something small like L4, with a few very well-defined tasks passing messages between each other. If you need to use Linux, run it on a separate machine that communicates with the safety-critical systems, but is not safety-critical itself.
Heh. Yeah, and VMware to run Windows Vista.
There. See, she can be reasonable. Continue with the operation; you may fire when ready.
Linux is good and all, but would you really trust it for critical safety systems? Why not use something that's actually designed for that purpose?
What the hell? Didn't we learn like 20 years ago that in-band signalling is a security nightmare? Why was this guy able to reprogram the ATM without opening up the case?
Agreed. But then again, we're not 12-year-olds.
It not anything nearly that general. Or, at least, we don't know that it is. What we know is that we've tried applying patents to software, and over the last few decades, it's proven to be detrimental.
Personally, I think you should be able to file a patent on nearly any invention, but patents should be enforced in different ways, depending on how the technology is being used. If you're suing over the technology being used in software, you get nothing, or maybe enforcement for 2 years, tops. If it's in an ASIC, maybe 5 years. Pharmaceuticals, 20 years (or whatever). This would all be for the same patent, but you get monopoly power over various sectors of the economy for different times (and under different terms). Ongoing monitoring would result in regulatory changes, as necessary to promote progress.
Indeed. Look at crypto export regulations. A lot of people now think that cryptography isn't meaningfully regulated, but in reality, only mass-market software is free from the onerous restrictions. If you start selling, say, a secure wireless keyboard over the Internet, you can still be charged with a crime. (Why do you think there are *still* no actually-secure wireless keyboards on the market?)
Or they could "innovate" a new bus architecture, which happens to have HDMI or something built-in, and finally drop support for PCI and ISA.
Let's see. Symantec's business model is selling products that work around Windows's brokenness. Now Microsoft is trying to fix Windows (though I doubt they'll be successful), and so Symantec is whining.
Adobe made and advertised PDF as an open standard. Now they're complaining that the standard is being implemented.
Personally, I'd enjoy seeing Microsoft barred from providing security fixes and PDF support, but that's just because I think Windows is already a hopeless shipwreck that will benefit the world by quickly reaching the end of its life. =)
Seriously, though, I'm not actually sure that Microsoft should be able to enter all these markets. The company should have been split up in 1999.
...
I found one case where the whitespace was a hindrance, and it was only because I was trying to use Python directly as a templating language, which is dumb anyway. Even then, it still worked.
This was the problem: I effectively had code that did this:
I was worried about the trailing brace, which in Python, was supposed to be either a line of code, or a comment character, indented at the appropriate location. Even in another language, it was a stupid design. It's hard to match a single closing brace in the middle of nowhere with its corresponding opening brace, unless you have a good editor, which you have already said won't be the case. In Python it was slightly worse, because you'd end up with comment characters that had a particular significance, but it's not like I should have been doing that anyway.
Let's recap: the "whitespace issue" has just never been a serious problem, and has been quite helpful for when I've had to debug other people's code. You, so far, haven't convinced me that it can be a real problem, because you haven't given me any real examples of where Python was the wrong choice of language due to the way it handles whitespace. I repeat: The whitespace issue itself has never been a serious enough problem to render Python less suitable than some other language for any job I've worked on, and it has sometimes been beneficial..
So far, the only thing you have established (well, I was the one to establish it) is that control structures based on whitespace are, in at least one case, suboptimal. That's a far cry from your generalization:
On the plus side, you haven't called me homosexual or a Nazi or something like that yet, which is quite a surprise, given that this is Slashdot. :)
So you're saying that programming languages should be designed around Microsoft Word? And for the record, I see no reason why you couldn't edit Python code using MS Word. Even if you couldn't, you could just install gvim for Win32 or just dump it into a folder and run it from there (if you don't have admin access to the machine), or use Notepad, or whatever.
You're grasping at straws. So far, you've given me all sorts of reasons why whitespace significance could hypothetically be a problem, but no examples of how it actually is a meaningful problem in real life. I cringed at the thought of Python's whitespace significance when I first used it. I got over it in about a week, because it just isn't a problem.
I have found exactly one scenario where the whitespace handling is a problem: in mod_python Python Server Pages (basically inline-able Python code, like you can do with PHP). Even there, it worked, but I just didn't trust it to be maintainable. On the other hand, most people consider inlining code that way to be bad practice anyway. Furthermore, if you use the more elaborate Spyce intead of mod_python's built-in methanism, you can use braces around blocks anyway.
The bottom line is that I've been using Python, often in a professional capacity, for about 5 years, and the "whitespace issue" has just never been a serious problem, and has been quite helpful for when I've had to debug other people's code. You, so far, haven't convinced me that it can be a real problem, because you haven't given me any real examples of where Python was the wrong choice of language due to the way it handles whitespace.
What, so I have to invent something in order for you to accept that somebody might invent something?
I dunno, something like MythTV maybe?
Like what editor? Even if your editor converts tabs to spaces or something, Python's parser can handle that just fine. All it does it look at the indentation of the current line relative to the indentation of previous lines.
If you're using an editor that mangles whitespace to such an extent that Python's parser can't handle it, and then submitting the results to some source code repository, you're creating a maintenance headache anyway.
Unless you're going to provide specific examples, it sounds more like a problem of your using a chisel as a screwdriver than a legitimate problem with the language.
I'm referring to making hardware that interfaces with other hardware that implements HDCP. Copy protection is an interoperability disaster by design.