Heh. As good as LOTR movies were, I was *really* irked by what they nuked.
So, in this case, there will be no Battle of the 5 Armies; instead they're going to skip and dance along a Yellow Brick Road (the Old Road recently was repaved) all the way back to Hobbiton.
You sir, are correct.
The opinion was my own, and even as such was horribly misrepresented here without any context. I never suggested an Open Source strategy was in question, only that Open Development was questionable.
Okay, this is not anonymous. I had forgotten my password. But yes, those clarifications above are from me. The same as the poster.
The subject of this article is totally, and completely wrong. Open source was never in question. Only Open Development.
A common practice in kernel programming when encountering a totally unexpected situation is to "panic". The unexpected situations where this is acceptable are often one of two classes:
1) critical failure of a critical piece of hardware (e.g. your root disk going out to lunch), uncorrectable memory errors (but detectable), etc.
2) programming errors. (generally "bugs".) When developing code that makes certain assumptions, its often a good idea to validate those assumptions with something called an "assertion". (For example, an assumption that a linked list is properly terminated can be checked, or that the caller owns a particular lock, etc.)
In both cases, the response is to "crash" (or "panic").
Why do we do this? First, we've encountered a situation from which we do not have any realistic hope of recovering... so rather than risk data corruption or worse problems later down the road, we crash, to "stop the hemorrhaging" so to speak.
Second, this a good panic will also cause a dump of the system state to be taken, so that it can be analyzed later. In the case of hardware failure, it may give some clue as to what the bad component is that needs to be replaced. In the case of a programmer error, it often provides the details necessary to find and fix the bug.
Its not unreasonable to believe that situations like this could come up for application programs as well.
However, one thing that is _unacceptable_ for a kernel to do, is to crash just because a user happened to send bad input, or a network happened to spew bad data. (Errors _inside_ the chassis can cause a panic... errors from _outside_ the chassis should not.)
TPM is just a way of saying "secure key store". Given a TPM (and put it in the TV display, rather than in the player), it is pretty much possible to secure stuff so that the only way to break will require a high degree of sophistication and an electron scanning microscope. (And in some cases, even that might not be good enough. At very high levels of security devices are shielded against most or all forms of radiation, and removing the shield erases the key store. This is called "active countermeasures" in FIPS 140-2, IIRC.
TPM is like a powertool. It can be used for great good. It can also be used for great evil. Which it does depends on whose hands it is in.
(TPM, or similar approaches are very, very useful for things like secure transaction processing, digital security, platform assurance (i.e. guarantee that your OS load hasn't been compromised with a keylogger), and similar things.)
TPM can also be used to secure media delivery. However, in order to really prevent sophisticated pirates from stealing the HD content, the _entire_ data path must be encrypted. This includes all the electrical signaling up to and including the pixels themselves.
Then the next level of sophistication will be when somebody figures out how to use some kind of high-speed CCD or somesuch to capture the individual pixels on a high-resolution display. Of course the kind of gear required to do this would really only be worthwhile to large-scale commercial pirates -- and I wouldn't be surprised to find if _those_ guys also tried to protect the data stream against copying -- after all their illegal copies represent an income stream for them as well! (Though lacking keys, it might be hard for them to do so.
TPM properly done can certainly prevent casual piracy.
The best solution to this whole problem is not to purchase DRM'd content if you care about this kind of thing. Or, just accept that when you buy a physical copy of the media, you're pretty much going to have to accept the limitations of using just that media.
As to the concern about the fact that some studios put un-skippable ads and such on the media -- well, wait for reviews, and if it bothers you that much, don't buy the media. If enough people vote with their wallets then studios will figure it out, eventually, and give people what they want.
Oh, and one more thing, nobody should assume that they have a God-given right to watch whatever movies or listen to whatever songs they want. The distribution companies are not legally obligated to make this content to you in the first place (in any form), after all.
It ticks me off when people bitch and complain about DRM and such, and then go pirate stuff. If it bugs you, don't access the content at _all_. Your time would be better spent writing letters to your legislators and the media execs than stealing/borrowing/pirating (or whatever you want to call it) content that you have no legitimate right or need to access. Or even better yet, spend some time and money finding alternative content that fits with your ideals. (I think even more than lost sales, sales lost to a competitor will appeal most strongly to media execs.)
An important distinction here: patents are intended to reward the inventor in the short term, in exchange for giving the invention/creation back to benefit society at some point in the future.
This is one of the main reason that patents are public. If the inventor wanted to keep a true monopoly on the creation, he would keep it a trade secret. (Compare the handling of RSA vs RC5 encryption schemes.)
Of course, with hardware inventions, it might be hard to keep the product a trade-secret for very long.
Ultimately, I strongly feel that nobody should ever have a perpetually legally enforced monopoly. In the near term (the length of which is the subject of some debate), a monopoly is a nice reward.
Copyright is different, and has a necessarily longer term, although current moves by media owners to lengthen copyright to insane time frames is also nutso. (Anything longer than 20 years past date of creation seems unjustifiable in my mind.)
Heh. I have "laptops" (well mobile servers might be a more accurate description) that are several times more expensive than $5000. And no, they don't run Windows.
Its amazing how expensive things get when you put a pair of UltraSPARC IIIi processors in a mobile unit.
But I also consider these units a lot more secure than a typical Windows box. They can run Trusted Solaris (though at the moment I'm only running Solaris 10 and Open Solaris on them.)
These are obviously an exceptional case (I work for the manufacturer, and wouldn't buy one for personal use), and are targetted for extreme applications. (Think DoD type applications.:-)
Heh. I still _play_ with my NES. The carts are getting old, but the most important one, Dr. Mario, still works.:-) Still looking forward to the day when Wii VC includes Dr. Mario.
But for truly vintage hardware, look for any of these:
* TRS-80 model 1. * Anything from Commodore, but especially a PET (though I still think the C64 is a great machine) * PDP-10 * Anything VAX * early SPARC systems * original IBM PC/XT * first generation Compaq (early "luggable") * first generation macintosh (early GUI designs)
The best example I can think of is (on Solaris, but it applies to Linux and Windows as well) is the web. NCSA Mosaic (yes I used it) was a nice, clean browser, that had very few features. No tabs, no flash, no java, no javascript, etc. It was great at displaying hypertext though, and even supported some simple features like inline graphics and various fonts etc. (And could use helper applications for things like audio, postscript, etc.) Back in 1993 this configuration ran comfortably on a Solaris machine with as little as 16 MB. (On Linux, even as little as 8 MB.)
Fast forward to today. Now we have tables, flash, java, and that "goodness" (for some value of "goodness"). Oh yeah, and caching, lets add that to boost speed up. And alpha blended PNGs, and... and... etc. So now firefox typically is consuming ~1GB RAM, and I periodically have to restart it just to convince it to give me back some memory.
Is this annoying, hell yes!
Do I want to go back to using NCSA Mosiac? Hell no! (There is Opera, but well, that's another issue... it crashes fairly consistently for me.)
A lot of these features add little value beyond aesthetic appeal, but we've become used to them, and frankly, most users are unwilling to go backwards to get them.
I will remind everyone that FreeDOS 1.0 is available, and you can download older versions of Linux and such, so that you can run your ancient software on the latest platforms, and see it go blazingly fast. But even so, most people won't like the result -- the masses want eye-candy, and ease of use, and.... and all that stuff sucks up machine resources like crazy.:-)
FWIW, I think some of my "largest" contributions to projects I've worked with have been "negative lines of code". I.e. by simplifying a project or removing redundant/duplicate code, I've probably removed many thousands of lines of code from the operating systems projects I've worked on. But program managers and marketdroids dont' care about that -- they can't sell "runs in 20% less memory than the last version" as easily as they can sell whatever new feature they're hyping.
My wife, her mother, and I have spent probably hundreds of hours playing Dr. Mario in competitive mode. And we still do. This is on an original NES, that we will probably still keep around until it finally dies.
I am really looking forward to seeing Dr Mario on Wii VC, and is one of the arguments I used to persuade my wife to purchase one.
I do embedded development work, and I can tell you that I would never, ever consider Linux as my first choice. The companies that offer prebuilt development packages charge an arm and a leg, and the Linux code base, is not really well designed for portability/embeddability. (The fact that it is used in such environments is a testament to the sheer brute force behind some Linux "ports".)
Contrast this to NetBSD, where development tools are part of the package, are free, and completely cross-buildable. And the system is designed from the get-go for cross-building. (My development machines run Solaris, and generally apart from a few toolchain fixes which I've committed upstream, I have not run into any signficant issues building for any of the 57-odd platforms that NetBSD supports.) Combined with the potential to build very lean kernels, a license that is very friendly for commercial redistribution, and various other features, if you want a free 'nix for embedded use, NetBSD should be your first choice. (Exception: if your platform needs goood SMP support. NetBSD fails miserably there.)
In fact, I've used NetBSD and ported it to a number of platforms, including Au1550 and Atheros AR5312 WiSoC platforms. Porting to the new Atheros platforms took a couple of weekends of effort. No big deal. (I've recently committed AR5315 support for the Meraki Mini wireless AP -- http://www.meraki.net/ -- and will be adding support for the SPI connected flash memory in the next week or so.)
There is even one main vendor that sells commercial support for embedded NetBSD, if you need commercial support. (Wasabi, I won't post their URL here.) You shouldn't even need that support though, unless you need custom device drivers and can't find or contract out the development expertise. (A number of consultants are available for custom NetBSD development. Many of whom have CVS commit access. Myself among them.:-)
It still amazes me that companies choose Linux over NetBSD in this particular market.
Hmmm... but, assuming a 5km ring, what is the maximum speed for 10g? Again, I'm sorry, but I don't recall the exact force equations involved (and I haven't got a freshman physics text handy)
Expanding on the hybridization idea, if you can get above the bottom few 10kms of atmosphere, your rockets (ramjets might not be effective at that altitude) can impart a lot more effective acceleration because they don't have to fight against atmospheric effects. (There is the n^2 fall-off in gravity's influence as well, but I suspect that's trivial at those kinds of differences compared to atmospheric drag.)
Uh, I think the 2000g is not from direct linear acceleration, but from centripetal acceleration. I.e. at the start of the acceleration process, the G forces are substantially less. But as you come up to speed, you have centripetal acceleration resulting from traveling Mach 23 around a 2Km ring. Its been a long, long time since freshman physics, so I don't recall the exact calculations involved, but I seem to recall they were simple. Maybe someone else can post the math.
But the upshot of this is that 2000g is the peak acceleration, and is not sustained for the entire acceleration period.
I would like to see some references to comparing linear accelerators with the ring concept. I suspect that a combined approach, would be quite useful. E.g. imagine a 2Km ring used to accelerate to some mid-range mach number (e.g. mach 5 or some such), where the centripetal acceleration is low -- human sustainable maybe, followed by a longer linear acceleration (maybe another 5 Km or somesuch) to crank the unit up to orbital velocity. This may help mitigate the power considerations with a strictly linear approach, while avoiding the worst of the G forces imposed by a ring.
An interesting engineering problem would be to design a system that assumes some basic properties: maximum ring size of say 2km (or pick some other arbitrary range. I'm sure 5km rings are doable out in the desert), maximum G force imposed determined by human tolerance -- what are the forces endured by shuttle astronauts?, maximum power output determined by a typical nuclear reactor (assume sustained output, though one could imagine charging a bunch of capacitors to generate a higher burst... not sure that we have capacitor technology to handle that kind of load though), launch angle of ~30 degrees. (Though I think with a long linear ramp, we could exceed that angle and get to a much higher degree -- e.g. add 30 degress to an incline created by a slope, maybe get to 45 or 50 degrees.)
Another interesting idea would be to hybridize somewhat. Add ramjets or rockets to the craft to kick in a few seconds after launch. Now you don't need a full mach 23 at launch, but if you can loft to mach 10 or so, and hit 20-30km, you can get the rest of the way to orbit with a lot less fuel. Of course, that means your launcher has to cope with additional weight, increasing power requirements on the ground. I'm not sure how the trade-off works. Sounds like fun math, though.
Don't get me wrong. I'm a staunch capitalist myself.
But the main difference between capitalism and communism is the difference between an individual working for self gain and an individual working for the greater good.
A true altruist will prefer communism where everybody gets basically equal treatment/salary, etc. But in a real world, communism doesn't work, because there are people like Ms. Dunn, and even people with otherwise good morals are going to work much harder for their own self-gain than for some "common" good. (Its not true of everyone. But I conjecture that it is true of _most_ people.)
In other words capitalism takes advantage of people's self-interest/greed, and only breaks down when people get _too_ successful. Communism breaks down right at the start. Neither system is perfect, but it is much easier to apply the necessary corrections to capitalism (e.g. anti-trust laws, etc.) than to communism (e.g. motivating a work force to be productive for some "greater" good.)
The main exception to this is probably when cooperating against a common foe, as in war time. In those cases, people often set aside their capitalistic tendencies and are willing to fight for their ideology/homeland/patriotism, whatever. But war is just capitalism practiced between nations with guns.:-)
Yes, this is very useful but not the only aim of the GPL. The aim of the GPL is to give the user all 4 freedoms defined by the Free Software definition and protect this freedoms.
And i think whether you agree with the Free Software definition, the FSF or RMS or someone else you can see that the GPLv2 have done this in the past really well and things like DRM have created some holes for the present and the future which will be closed by GPLv3. So that GPLv3 will do an as good job today like the GPLv2 did yesterday.
GPLv3 will do nothing for anyone if nobody uses it. And the restrictions and limitations I see in it are likely to be large barriers to commercial adoption.
Lets face it folks, if it weren't for commercial adoption of GPLv2 software, Linux would still be a two-bit player used by geeks and occasionally in academia. It would not be touted as an enterprise OS with large companies like IBM standing behind it.
To give a quick answer: you cannot modify or update the software (from source) on a FIPS 140-2 (at least at levels 2 and above) system (at least within the "security boundary" without invalidating the FIPS certificate.
And any system which allowed you to do so without guaranteeing that the product identified itself as operating outside of FIPS compliance could never, ever get a ceritifcate.
The problem is that if you can fix a bug, you can also introduce a bug. The only way to get the bug fixed is to ask the vendor to fix it, and send you an update. And technically this requires the vendor to get an update to the FIPS 140-2 certificate, as well. Anything else you do breaks the FIPS 140-2 compliance. (In practice, small bug fixes from the vendor are typically allowed as "updates" to the original certificate.)
All you have to do is look at the recent revokation of the OpenSSL FIPS 140-2 certificate (which was only a level 1 cert IIRC) to understand how critical this is -- "end users" as such, are not trusted where code updates are concerned.
All code within the boundary must be trusted/assured. The only way to assure this, is to ensure that the code is exactly what was certified. Cryptographic signatures are the normal way to do this while still giving some ability to update firmware.
By the way, there are some systems that have a "non-FIPS" mode. This has to be indicated by an LED or clear banner or somesuch. If you could run arbitrary code that could masquerade as FIPS compliant, it would make the certificate worthless -- and so I believe it is impossible to get a FIPS certificate for a system which does not take measures to prevent this kind of update to code within the security boundary.
The question is who decides what code is trusted and what code is untrusted? Maybe you can give me the answere for the FIPS-140-2. If the company, government,... who uses this FIPS 140-2 product can decide which software is trusted and which is untrusted, than this is OK with GPLv3. But if someone else will decide it than it's not ok because than the company, government, etc. will no longer control their own IT infrastructure.
This kind of secuurity would be a joke. If i can't control my own security than i don't think it it's a good security system. And security which can be controlled by the person, company, government which should be protected through it is completly ok with GPLv3.
Its more complicated than you think. Code and hardware together are verified by independent labs, which perform the certification according to government standards. The labs will most assuredly not grant a FIPS 140-2 certification that allows arbitrary code to run inside the security boundary, whether supplied by the customer or not.
Generally part of the validation process includes full disclosure of a "security policy", which will include things like how the security of firmware updates is managed. In general, the supplying company is trusted to ensure that 3rd parties are not able to circumvent this process. Typically this means having signed firmware, or even having firmware that simply cannot be field updated.
Actually, this raises a good point. I don't think the language of the GPLv3 requires that software be field updateable. It merely stipulates rules that if it is updateable, it has to be updateable by anyone. Maybe that will be a solution some vendors will seek -- require a factory RMA to upgrade software on the unit. Yikes!
I think you have to see it more from the position of a "user" and not from somewhere outside. Modifying software and than can't run it doesn't make much sense.
No, I see it from a developer. I can use the _knowledge_ (i.e. the source code) to create derivative products, which run on entirely different hardware. This is very, very useful.
The question is, do you believe GPL is about protecting the user's rights, or about ensuring that the knowledge and effort that goes into a product's development is not "locked up". In the case of the GPLv2, I believe the latter, whereas GPLv3 makes a strong statement to the former. This distinction is critical!
GPLv2 ensures innovation is not lost, and generally works to improve the state of the art. GPLv3 abandons that (IMO) by focusing on the user. As a developer of open source code (and I am such), I don't care if you, the user, are able to hack on a specific piece of equipment shipped with my software or not -- I just want to make sure that if a company is going to stand on my shoulders, so to speak, that they reciprocate by giving the community back their improvements.
This philosophical difference is the foundation of the argument between RMS and Linus, I think.
The ability to change firmware, etc. should be determined by market forces -- people will vote with their feet if it is important. In some cases, it isn't important -- or as in the FIPS solution -- it can actually be considered a weakness.
In the end, GPLv3 will probably be irrelevant, because I can't imagine it gaining much momentum outside of FSF-sponsored projects -- I just don't see commercial entities (even those that have vocally supported OSS) getting behind it. (Sure, they may pay it lip-service, but I don't look to see much beyond that.)
There is another major point that the Linux fans are missing here.
Having source makes the device useful for something _other_ than Linux. Like NetBSD.
ATI have historically been easier to work with than Nvidia in this regard. One can get source for some ATI products. And they are willing to work under NDA. I've even produced a radeonfb for NetBSD using information that was under NDA (and had never been released outside ATI before), and ATI let me release the drivers back to the community under a BSD license.
Compared this to Nvidia, where you can't even get docs under NDA.
Nearly all the information needed to produce good 2D accelerated radeon drivers (including multiple monitor/desktop support, etc.) is out there. I should know -- I'VE DONE IT!
What isn't there is any information relevant to 3D acceleration. ATI is being very, very tightlipped about their 3D features. In the past docs were available under NDA, but I'm not sure this is even true anymore.
Even so, there are some 3D OpenGL support for radeon in OSS, you just have to hunt around for it.
I think you are wrong. For example a company can use GPLv3 code, sign it and use it with their DRM hardware to make sure that only this software runs. They don't redistribute hardware+software in a form which would deny freedom to the recipient of the system they just use it to create security for their IT infrastructure and this will be OK with GPLv3.
Are you familiar with FIPS-140-2? Have you ever designed a FIPS 140-2 product? I have (level 3). For any level above -1, you must have a robust firmware/upgrade management scheme which explicitly ensures that untrusted code is not allowed to run within the "security boundary". Otherwise, for example, someone could download their code, and (because it is arbitrary code) it can light the "FIPS secure" indicator LED, while ftp'ing all your secure key data to some random site. And because the "FIPS secure" indicator light is on, the folks using the device (which might be different from the person up installed the "rogue" firmware on it) are unaware that the device is compromised.
That's not the point. If you sell hardware with your software you can do what you want. But if you sell e.g. computers with GPLv3 Software which says i have the right to modify the software than you have to make sure that i can exercise this rights and can't prevent it with DRM.
Its not just modification of the software that is at issue, it is installation of said software on said hardware that is at stake. GPLv2 did not place this requirement -- but it encouraged derivative product development. GPLv2 was (for the most thing) a good thing for driving and deriving additional innovation for the benefit of the OSS community from commercial interests. GPLv3, as far as I can tell, abandons this in a (IMO fruitless) attempt to prevent DRM and closed-hardware derivative solutions.
GPLv2 was inconvenient enough for commercial developers, but it (or rather the quantity and quality of software released under it) levelled the playing field so that barriers to entry were removed for a lot of commercial competition.
With GPLv3, I think commercial interests will be driven away from GPLv3 software because it imposes too many restrictions, and developers will move to altenrative solutions. And, there are good alternatives for almost everything -- *BSD and Solaris are both good examples. About the only piece of GPL software for which there is not a good alternative under an alternative license is GCC, and maybe binutils. And, generally speaking, these aren't distributed on the embedded solutions that would be inconvenienced by GPLv3.
If Linus wants to continue to enjoy popular support from companies like IBM, Sun, HP, and even pure software companies like RedHat and Linspire, he is wise to stay away from GPLv3. (Heck, I think GPLv3 would make developments like Linspire's Click-N-Run support commercially unsupportable.)
The license itself is short and sweet, and easy to understand. Or at least so I deem, but of course IANAL.
I have no idea what software Microsoft has licensed under this license, but a casual read of it looks like the license should be certifiable by OSI. As far as I can tell, the only potentially confusing issue is the patent retaliation clause.
In most other respects, it looks like a simpler version of the GPL, including being viral. I can't imagine why MS wouldn't want it blessed by OSI. Probably they just don't want to be recognized for giving source away even when they do so. Heck, they might be worried that it would scare off investors who consider Microsoft's IP portfolio as a reason for buy MS shares.:-)
Now, it probably is a Good Thing that it isn't blessed, because the last thing we want is another viral license that also happens to be incompatible with GPL. (The patent retaliation makes it GPL-incompatible.) Life is hard enough figuring out Open Source license as it is.
Stallman/GPLv3 want to ensure that companies can't release hardware with GPLv3 software unless you allow customers to replace the software on that hardware. How you do that is effectively up to you.
This is about making sure everyone can access your hardware. The DRM implications are a side effect. (Yes, FSF happens to be strongly opposed to DRM, so its a bonus in their view point.) This makes, e.g. signed firmware (or rather a process by which signed firmware can do things that unsigned can't) irrelevant.
This is a serious problem for certain kinds of applications that have nothing to do with DRM, and everything to do with security. Under these rules, for example, it would be impossible to use GPLv3 software in functions conformant with FIPS-140-2 (the federal standard for cryptographic devices/software).
Now, I happen to agree with Torvald's supposed view, which is that the GPL is useful in that it ensures that the innovation that exists in GPL software is not lost, and that if commercial entities are going to stand on your shoulders (as a GPL author) then it is fair to ask them to accord the community the benefit of their improvements. This is entirely useful, and doesn't prevent companies from building closed-hardware with GPL sources.
The problem is that some GPL zealots believe that if they purchase a piece of hardware, they should have the right to replace the software on it. I don't think that is a natural right (or rather, I don't think it is an obligation that the manufacturer should have to help you). Remember the event that has been attributed to the birth of the GPL was the fact that Stallman couldn't replace some software for a printer. I think RMS is concerned that GPLv2 combined with cryptographic signing doesn't address his original concern in this regard -- hence GPLv3.
By enforcing this view, I think the GPLv3 does the OSS community a grave disservice, by fragmenting views and creating situations where license incompatibility gets even worse. Commercial entities that heretofore have embraced GPLv2 will shun GPLv3.
This is also true of the provsion that requires companies which provide network services to release their enhancements. How much GPL software do you think Google uses? How much of it will Google continue to use in the face of GPLv3? Or will they just abandon GPLv3 software in favor of commercial or alternate open source solutions? It could be a great thing for my two favorite OSS communities -- NetBSD and Solaris -- if Linux ever adopts the GPLv3.:-)
As I said, GPLv3 is a grave disservice to the OSS community, and even without the implications for DRM'd media content.
FYI, NetBSD works great on most sun4m hardware. It doesn't run on Ultra3 yet, but the sources for OpenSolaris are there, so the information is out there to fix that problem. (I might even start working on an Ultra3i port for NetBSD, I haven't decided yet.)
And there is talk about reviving sun4m in OpenSolaris. (From a corporate standpoint, I totally understand why Sun ditched sun4m hardware. It is a PITA to maintain legacy support for old platforms, and sometimes that support prevents you from going in new directions.) I think if the community pushes hard enough for sun4m to be revived, it will happen. Likewise, the PPC port is totally a community effort, and probably has more value to Sun as an exercise in portability than keeping the sun4m port alive has.
Also, you can probably go back in the svn history to get an early sun4m-capable build.
The other thing to consider is that, some legacy software might have ownerships or NDA considerations where Sun can't simply just open source the code. I'm not sure how much of this is relevant to sun4m. I think very little, in this particular case. It probably wouldn't be too hard to revive sun4m support if you are that committed to it! Most of the rest of us, however, recognize that there is little value even in those SS20 class systems -- the UltraSPARC systems that can be had for dirt cheap now (e.g. a U10 is probably ~$100 on ebay) are much, much more capable than any sun4m system you are likely to find.
The exception to this is certain sun4d hardware, but anyone who still has a sun4d powered up should probably be shot for wasteful power consumption.
I suppose you'd also like Sun to release open sources for their older sun3 and sun2 hardware as well? Because its really urgently important that those systems still be able to run OpenSolaris!
Slashdot Mirror
The logical break in the story is after the spiders, with the Dwarves still imprisoned in the wood elf's kingdom.
Heh. As good as LOTR movies were, I was *really* irked by what they nuked. So, in this case, there will be no Battle of the 5 Armies; instead they're going to skip and dance along a Yellow Brick Road (the Old Road recently was repaved) all the way back to Hobbiton.
You sir, are correct. The opinion was my own, and even as such was horribly misrepresented here without any context. I never suggested an Open Source strategy was in question, only that Open Development was questionable.
Okay, this is not anonymous. I had forgotten my password. But yes, those clarifications above are from me. The same as the poster. The subject of this article is totally, and completely wrong. Open source was never in question. Only Open Development.
Anyone here do kernel programming?
A common practice in kernel programming when encountering a totally unexpected situation is to "panic". The unexpected situations where this is acceptable are often one of two classes:
1) critical failure of a critical piece of hardware (e.g. your root disk going out to lunch), uncorrectable memory errors (but detectable), etc.
2) programming errors. (generally "bugs".) When developing code that makes certain assumptions, its often a good idea to validate those assumptions with something called an "assertion". (For example, an assumption that a linked list is properly terminated can be checked, or that the caller owns a particular lock, etc.)
In both cases, the response is to "crash" (or "panic").
Why do we do this? First, we've encountered a situation from which we do not have any realistic hope of recovering... so rather than risk data corruption or worse problems later down the road, we crash, to "stop the hemorrhaging" so to speak.
Second, this a good panic will also cause a dump of the system state to be taken, so that it can be analyzed later. In the case of hardware failure, it may give some clue as to what the bad component is that needs to be replaced. In the case of a programmer error, it often provides the details necessary to find and fix the bug.
Its not unreasonable to believe that situations like this could come up for application programs as well.
However, one thing that is _unacceptable_ for a kernel to do, is to crash just because a user happened to send bad input, or a network happened to spew bad data. (Errors _inside_ the chassis can cause a panic... errors from _outside_ the chassis should not.)
I think M$ have some debugging to do...
TPM is just a way of saying "secure key store". Given a TPM (and put it in the TV display, rather than in the player), it is pretty much possible to secure stuff so that the only way to break will require a high degree of sophistication and an electron scanning microscope. (And in some cases, even that might not be good enough. At very high levels of security devices are shielded against most or all forms of radiation, and removing the shield erases the key store. This is called "active countermeasures" in FIPS 140-2, IIRC.
TPM is like a powertool. It can be used for great good. It can also be used for great evil. Which it does depends on whose hands it is in.
(TPM, or similar approaches are very, very useful for things like secure transaction processing, digital security, platform assurance (i.e. guarantee that your OS load hasn't been compromised with a keylogger), and similar things.)
TPM can also be used to secure media delivery. However, in order to really prevent sophisticated pirates from stealing the HD content, the _entire_ data path must be encrypted. This includes all the electrical signaling up to and including the pixels themselves.
Then the next level of sophistication will be when somebody figures out how to use some kind of high-speed CCD or somesuch to capture the individual pixels on a high-resolution display. Of course the kind of gear required to do this would really only be worthwhile to large-scale commercial pirates -- and I wouldn't be surprised to find if _those_ guys also tried to protect the data stream against copying -- after all their illegal copies represent an income stream for them as well! (Though lacking keys, it might be hard for them to do so.
TPM properly done can certainly prevent casual piracy.
The best solution to this whole problem is not to purchase DRM'd content if you care about this kind of thing. Or, just accept that when you buy a physical copy of the media, you're pretty much going to have to accept the limitations of using just that media.
As to the concern about the fact that some studios put un-skippable ads and such on the media -- well, wait for reviews, and if it bothers you that much, don't buy the media. If enough people vote with their wallets then studios will figure it out, eventually, and give people what they want.
Oh, and one more thing, nobody should assume that they have a God-given right to watch whatever movies or listen to whatever songs they want. The distribution companies are not legally obligated to make this content to you in the first place (in any form), after all.
It ticks me off when people bitch and complain about DRM and such, and then go pirate stuff. If it bugs you, don't access the content at _all_. Your time would be better spent writing letters to your legislators and the media execs than stealing/borrowing/pirating (or whatever you want to call it) content that you have no legitimate right or need to access. Or even better yet, spend some time and money finding alternative content that fits with your ideals. (I think even more than lost sales, sales lost to a competitor will appeal most strongly to media execs.)
An important distinction here: patents are intended to reward the inventor in the short term, in exchange for giving the invention/creation back to benefit society at some point in the future.
This is one of the main reason that patents are public. If the inventor wanted to keep a true monopoly on the creation, he would keep it a trade secret. (Compare the handling of RSA vs RC5 encryption schemes.)
Of course, with hardware inventions, it might be hard to keep the product a trade-secret for very long.
Ultimately, I strongly feel that nobody should ever have a perpetually legally enforced monopoly. In the near term (the length of which is the subject of some debate), a monopoly is a nice reward.
Copyright is different, and has a necessarily longer term, although current moves by media owners to lengthen copyright to insane time frames is also nutso. (Anything longer than 20 years past date of creation seems unjustifiable in my mind.)
Heh. I have "laptops" (well mobile servers might be a more accurate description) that are several times more expensive than $5000. And no, they don't run Windows.
:-)
Its amazing how expensive things get when you put a pair of UltraSPARC IIIi processors in a mobile unit.
But I also consider these units a lot more secure than a typical Windows box. They can run Trusted Solaris (though at the moment I'm only running Solaris 10 and Open Solaris on them.)
These are obviously an exceptional case (I work for the manufacturer, and wouldn't buy one for personal use), and are targetted for extreme applications. (Think DoD type applications.
Heh. I still _play_ with my NES. The carts are getting old, but the most important one, Dr. Mario, still works. :-) Still looking forward to the day when Wii VC includes Dr. Mario.
But for truly vintage hardware, look for any of these:
* TRS-80 model 1.
* Anything from Commodore, but especially a PET (though I still think the C64 is a great machine)
* PDP-10
* Anything VAX
* early SPARC systems
* original IBM PC/XT
* first generation Compaq (early "luggable")
* first generation macintosh (early GUI designs)
The best example I can think of is (on Solaris, but it applies to Linux and Windows as well) is the web. NCSA Mosaic (yes I used it) was a nice, clean browser, that had very few features. No tabs, no flash, no java, no javascript, etc. It was great at displaying hypertext though, and even supported some simple features like inline graphics and various fonts etc. (And could use helper applications for things like audio, postscript, etc.) Back in 1993 this configuration ran comfortably on a Solaris machine with as little as 16 MB. (On Linux, even as little as 8 MB.)
... and... etc. So now firefox typically is consuming ~1GB RAM, and I periodically have to restart it just to convince it to give me back some memory.
... it crashes fairly consistently for me.)
.... and all that stuff sucks up machine resources like crazy. :-)
Fast forward to today. Now we have tables, flash, java, and that "goodness" (for some value of "goodness"). Oh yeah, and caching, lets add that to boost speed up. And alpha blended PNGs, and
Is this annoying, hell yes!
Do I want to go back to using NCSA Mosiac? Hell no! (There is Opera, but well, that's another issue
A lot of these features add little value beyond aesthetic appeal, but we've become used to them, and frankly, most users are unwilling to go backwards to get them.
I will remind everyone that FreeDOS 1.0 is available, and you can download older versions of Linux and such, so that you can run your ancient software on the latest platforms, and see it go blazingly fast. But even so, most people won't like the result -- the masses want eye-candy, and ease of use, and
FWIW, I think some of my "largest" contributions to projects I've worked with have been "negative lines of code". I.e. by simplifying a project or removing redundant/duplicate code, I've probably removed many thousands of lines of code from the operating systems projects I've worked on. But program managers and marketdroids dont' care about that -- they can't sell "runs in 20% less memory than the last version" as easily as they can sell whatever new feature they're hyping.
My wife, her mother, and I have spent probably hundreds of hours playing Dr. Mario in competitive mode. And we still do. This is on an original NES, that we will probably still keep around until it finally dies.
I am really looking forward to seeing Dr Mario on Wii VC, and is one of the arguments I used to persuade my wife to purchase one.
I do embedded development work, and I can tell you that I would never, ever consider Linux as my first choice. The companies that offer prebuilt development packages charge an arm and a leg, and the Linux code base, is not really well designed for portability/embeddability. (The fact that it is used in such environments is a testament to the sheer brute force behind some Linux "ports".)
Contrast this to NetBSD, where development tools are part of the package, are free, and completely cross-buildable. And the system is designed from the get-go for cross-building. (My development machines run Solaris, and generally apart from a few toolchain fixes which I've committed upstream, I have not run into any signficant issues building for any of the 57-odd platforms that NetBSD supports.) Combined with the potential to build very lean kernels, a license that is very friendly for commercial redistribution, and various other features, if you want a free 'nix for embedded use, NetBSD should be your first choice. (Exception: if your platform needs goood SMP support. NetBSD fails miserably there.)
In fact, I've used NetBSD and ported it to a number of platforms, including Au1550 and Atheros AR5312 WiSoC platforms. Porting to the new Atheros platforms took a couple of weekends of effort. No big deal. (I've recently committed AR5315 support for the Meraki Mini wireless AP -- http://www.meraki.net/ -- and will be adding support for the SPI connected flash memory in the next week or so.)
There is even one main vendor that sells commercial support for embedded NetBSD, if you need commercial support. (Wasabi, I won't post their URL here.) You shouldn't even need that support though, unless you need custom device drivers and can't find or contract out the development expertise. (A number of consultants are available for custom NetBSD development. Many of whom have CVS commit access. Myself among them. :-)
It still amazes me that companies choose Linux over NetBSD in this particular market.
Hmmm... but, assuming a 5km ring, what is the maximum speed for 10g? Again, I'm sorry, but I don't recall the exact force equations involved (and I haven't got a freshman physics text handy)
Expanding on the hybridization idea, if you can get above the bottom few 10kms of atmosphere, your rockets (ramjets might not be effective at that altitude) can impart a lot more effective acceleration because they don't have to fight against atmospheric effects. (There is the n^2 fall-off in gravity's influence as well, but I suspect that's trivial at those kinds of differences compared to atmospheric drag.)
Uh, I think the 2000g is not from direct linear acceleration, but from centripetal acceleration. I.e. at the start of the acceleration process, the G forces are substantially less. But as you come up to speed, you have centripetal acceleration resulting from traveling Mach 23 around a 2Km ring. Its been a long, long time since freshman physics, so I don't recall the exact calculations involved, but I seem to recall they were simple. Maybe someone else can post the math.
But the upshot of this is that 2000g is the peak acceleration, and is not sustained for the entire acceleration period.
I would like to see some references to comparing linear accelerators with the ring concept. I suspect that a combined approach, would be quite useful. E.g. imagine a 2Km ring used to accelerate to some mid-range mach number (e.g. mach 5 or some such), where the centripetal acceleration is low -- human sustainable maybe, followed by a longer linear acceleration (maybe another 5 Km or somesuch) to crank the unit up to orbital velocity. This may help mitigate the power considerations with a strictly linear approach, while avoiding the worst of the G forces imposed by a ring.
An interesting engineering problem would be to design a system that assumes some basic properties: maximum ring size of say 2km (or pick some other arbitrary range. I'm sure 5km rings are doable out in the desert), maximum G force imposed determined by human tolerance -- what are the forces endured by shuttle astronauts?, maximum power output determined by a typical nuclear reactor (assume sustained output, though one could imagine charging a bunch of capacitors to generate a higher burst... not sure that we have capacitor technology to handle that kind of load though), launch angle of ~30 degrees. (Though I think with a long linear ramp, we could exceed that angle and get to a much higher degree -- e.g. add 30 degress to an incline created by a slope, maybe get to 45 or 50 degrees.)
Another interesting idea would be to hybridize somewhat. Add ramjets or rockets to the craft to kick in a few seconds after launch. Now you don't need a full mach 23 at launch, but if you can loft to mach 10 or so, and hit 20-30km, you can get the rest of the way to orbit with a lot less fuel. Of course, that means your launcher has to cope with additional weight, increasing power requirements on the ground. I'm not sure how the trade-off works. Sounds like fun math, though.
Don't get me wrong. I'm a staunch capitalist myself.
:-)
But the main difference between capitalism and communism is the difference between an individual working for self gain and an individual working for the greater good.
A true altruist will prefer communism where everybody gets basically equal treatment/salary, etc. But in a real world, communism doesn't work, because there are people like Ms. Dunn, and even people with otherwise good morals are going to work much harder for their own self-gain than for some "common" good. (Its not true of everyone. But I conjecture that it is true of _most_ people.)
In other words capitalism takes advantage of people's self-interest/greed, and only breaks down when people get _too_ successful. Communism breaks down right at the start. Neither system is perfect, but it is much easier to apply the necessary corrections to capitalism (e.g. anti-trust laws, etc.) than to communism (e.g. motivating a work force to be productive for some "greater" good.)
The main exception to this is probably when cooperating against a common foe, as in war time. In those cases, people often set aside their capitalistic tendencies and are willing to fight for their ideology/homeland/patriotism, whatever. But war is just capitalism practiced between nations with guns.
GPLv3 will do nothing for anyone if nobody uses it. And the restrictions and limitations I see in it are likely to be large barriers to commercial adoption.
Lets face it folks, if it weren't for commercial adoption of GPLv2 software, Linux would still be a two-bit player used by geeks and occasionally in academia. It would not be touted as an enterprise OS with large companies like IBM standing behind it.
The problem is that if you can fix a bug, you can also introduce a bug. The only way to get the bug fixed is to ask the vendor to fix it, and send you an update. And technically this requires the vendor to get an update to the FIPS 140-2 certificate, as well. Anything else you do breaks the FIPS 140-2 compliance. (In practice, small bug fixes from the vendor are typically allowed as "updates" to the original certificate.)
All you have to do is look at the recent revokation of the OpenSSL FIPS 140-2 certificate (which was only a level 1 cert IIRC) to understand how critical this is -- "end users" as such, are not trusted where code updates are concerned.
All code within the boundary must be trusted/assured. The only way to assure this, is to ensure that the code is exactly what was certified. Cryptographic signatures are the normal way to do this while still giving some ability to update firmware.
By the way, there are some systems that have a "non-FIPS" mode. This has to be indicated by an LED or clear banner or somesuch. If you could run arbitrary code that could masquerade as FIPS compliant, it would make the certificate worthless -- and so I believe it is impossible to get a FIPS certificate for a system which does not take measures to prevent this kind of update to code within the security boundary.
Its more complicated than you think. Code and hardware together are verified by independent labs, which perform the certification according to government standards. The labs will most assuredly not grant a FIPS 140-2 certification that allows arbitrary code to run inside the security boundary, whether supplied by the customer or not.
Generally part of the validation process includes full disclosure of a "security policy", which will include things like how the security of firmware updates is managed. In general, the supplying company is trusted to ensure that 3rd parties are not able to circumvent this process. Typically this means having signed firmware, or even having firmware that simply cannot be field updated.
Actually, this raises a good point. I don't think the language of the GPLv3 requires that software be field updateable. It merely stipulates rules that if it is updateable, it has to be updateable by anyone. Maybe that will be a solution some vendors will seek -- require a factory RMA to upgrade software on the unit. Yikes!
No, I see it from a developer. I can use the _knowledge_ (i.e. the source code) to create derivative products, which run on entirely different hardware. This is very, very useful.
The question is, do you believe GPL is about protecting the user's rights, or about ensuring that the knowledge and effort that goes into a product's development is not "locked up". In the case of the GPLv2, I believe the latter, whereas GPLv3 makes a strong statement to the former. This distinction is critical!
GPLv2 ensures innovation is not lost, and generally works to improve the state of the art. GPLv3 abandons that (IMO) by focusing on the user. As a developer of open source code (and I am such), I don't care if you, the user, are able to hack on a specific piece of equipment shipped with my software or not -- I just want to make sure that if a company is going to stand on my shoulders, so to speak, that they reciprocate by giving the community back their improvements.
This philosophical difference is the foundation of the argument between RMS and Linus, I think.
The ability to change firmware, etc. should be determined by market forces -- people will vote with their feet if it is important. In some cases, it isn't important -- or as in the FIPS solution -- it can actually be considered a weakness.
In the end, GPLv3 will probably be irrelevant, because I can't imagine it gaining much momentum outside of FSF-sponsored projects -- I just don't see commercial entities (even those that have vocally supported OSS) getting behind it. (Sure, they may pay it lip-service, but I don't look to see much beyond that.)
Having source makes the device useful for something _other_ than Linux. Like NetBSD.
ATI have historically been easier to work with than Nvidia in this regard. One can get source for some ATI products. And they are willing to work under NDA. I've even produced a radeonfb for NetBSD using information that was under NDA (and had never been released outside ATI before), and ATI let me release the drivers back to the community under a BSD license.
Compared this to Nvidia, where you can't even get docs under NDA.
Nearly all the information needed to produce good 2D accelerated radeon drivers (including multiple monitor/desktop support, etc.) is out there. I should know -- I'VE DONE IT!
What isn't there is any information relevant to 3D acceleration. ATI is being very, very tightlipped about their 3D features. In the past docs were available under NDA, but I'm not sure this is even true anymore.
Even so, there are some 3D OpenGL support for radeon in OSS, you just have to hunt around for it.
Are you familiar with FIPS-140-2? Have you ever designed a FIPS 140-2 product? I have (level 3). For any level above -1, you must have a robust firmware/upgrade management scheme which explicitly ensures that untrusted code is not allowed to run within the "security boundary". Otherwise, for example, someone could download their code, and (because it is arbitrary code) it can light the "FIPS secure" indicator LED, while ftp'ing all your secure key data to some random site. And because the "FIPS secure" indicator light is on, the folks using the device (which might be different from the person up installed the "rogue" firmware on it) are unaware that the device is compromised.
Its not just modification of the software that is at issue, it is installation of said software on said hardware that is at stake. GPLv2 did not place this requirement -- but it encouraged derivative product development. GPLv2 was (for the most thing) a good thing for driving and deriving additional innovation for the benefit of the OSS community from commercial interests. GPLv3, as far as I can tell, abandons this in a (IMO fruitless) attempt to prevent DRM and closed-hardware derivative solutions.
GPLv2 was inconvenient enough for commercial developers, but it (or rather the quantity and quality of software released under it) levelled the playing field so that barriers to entry were removed for a lot of commercial competition.
With GPLv3, I think commercial interests will be driven away from GPLv3 software because it imposes too many restrictions, and developers will move to altenrative solutions. And, there are good alternatives for almost everything -- *BSD and Solaris are both good examples. About the only piece of GPL software for which there is not a good alternative under an alternative license is GCC, and maybe binutils. And, generally speaking, these aren't distributed on the embedded solutions that would be inconvenienced by GPLv3.
If Linus wants to continue to enjoy popular support from companies like IBM, Sun, HP, and even pure software companies like RedHat and Linspire, he is wise to stay away from GPLv3. (Heck, I think GPLv3 would make developments like Linspire's Click-N-Run support commercially unsupportable.)
Have you looked at the license. I confess I had not before I read this,but then I check it out at http://www.microsoft.com/resources/sharedsource/li censingbasics/communitylicense.mspx
The license itself is short and sweet, and easy to understand. Or at least so I deem, but of course IANAL.
I have no idea what software Microsoft has licensed under this license, but a casual read of it looks like the license should be certifiable by OSI. As far as I can tell, the only potentially confusing issue is the patent retaliation clause.
In most other respects, it looks like a simpler version of the GPL, including being viral. I can't imagine why MS wouldn't want it blessed by OSI. Probably they just don't want to be recognized for giving source away even when they do so. Heck, they might be worried that it would scare off investors who consider Microsoft's IP portfolio as a reason for buy MS shares. :-)
Now, it probably is a Good Thing that it isn't blessed, because the last thing we want is another viral license that also happens to be incompatible with GPL. (The patent retaliation makes it GPL-incompatible.) Life is hard enough figuring out Open Source license as it is.
Stallman/GPLv3 want to ensure that companies can't release hardware with GPLv3 software unless you allow customers to replace the software on that hardware. How you do that is effectively up to you.
This is about making sure everyone can access your hardware. The DRM implications are a side effect. (Yes, FSF happens to be strongly opposed to DRM, so its a bonus in their view point.) This makes, e.g. signed firmware (or rather a process by which signed firmware can do things that unsigned can't) irrelevant.
This is a serious problem for certain kinds of applications that have nothing to do with DRM, and everything to do with security. Under these rules, for example, it would be impossible to use GPLv3 software in functions conformant with FIPS-140-2 (the federal standard for cryptographic devices/software).
Now, I happen to agree with Torvald's supposed view, which is that the GPL is useful in that it ensures that the innovation that exists in GPL software is not lost, and that if commercial entities are going to stand on your shoulders (as a GPL author) then it is fair to ask them to accord the community the benefit of their improvements. This is entirely useful, and doesn't prevent companies from building closed-hardware with GPL sources.
The problem is that some GPL zealots believe that if they purchase a piece of hardware, they should have the right to replace the software on it. I don't think that is a natural right (or rather, I don't think it is an obligation that the manufacturer should have to help you). Remember the event that has been attributed to the birth of the GPL was the fact that Stallman couldn't replace some software for a printer. I think RMS is concerned that GPLv2 combined with cryptographic signing doesn't address his original concern in this regard -- hence GPLv3.
By enforcing this view, I think the GPLv3 does the OSS community a grave disservice, by fragmenting views and creating situations where license incompatibility gets even worse. Commercial entities that heretofore have embraced GPLv2 will shun GPLv3.
This is also true of the provsion that requires companies which provide network services to release their enhancements. How much GPL software do you think Google uses? How much of it will Google continue to use in the face of GPLv3? Or will they just abandon GPLv3 software in favor of commercial or alternate open source solutions? It could be a great thing for my two favorite OSS communities -- NetBSD and Solaris -- if Linux ever adopts the GPLv3. :-)
As I said, GPLv3 is a grave disservice to the OSS community, and even without the implications for DRM'd media content.
FYI, NetBSD works great on most sun4m hardware. It doesn't run on Ultra3 yet, but the sources for OpenSolaris are there, so the information is out there to fix that problem. (I might even start working on an Ultra3i port for NetBSD, I haven't decided yet.)
And there is talk about reviving sun4m in OpenSolaris. (From a corporate standpoint, I totally understand why Sun ditched sun4m hardware. It is a PITA to maintain legacy support for old platforms, and sometimes that support prevents you from going in new directions.) I think if the community pushes hard enough for sun4m to be revived, it will happen. Likewise, the PPC port is totally a community effort, and probably has more value to Sun as an exercise in portability than keeping the sun4m port alive has.
Also, you can probably go back in the svn history to get an early sun4m-capable build.
The other thing to consider is that, some legacy software might have ownerships or NDA considerations where Sun can't simply just open source the code. I'm not sure how much of this is relevant to sun4m. I think very little, in this particular case. It probably wouldn't be too hard to revive sun4m support if you are that committed to it! Most of the rest of us, however, recognize that there is little value even in those SS20 class systems -- the UltraSPARC systems that can be had for dirt cheap now (e.g. a U10 is probably ~$100 on ebay) are much, much more capable than any sun4m system you are likely to find.
The exception to this is certain sun4d hardware, but anyone who still has a sun4d powered up should probably be shot for wasteful power consumption.
I suppose you'd also like Sun to release open sources for their older sun3 and sun2 hardware as well? Because its really urgently important that those systems still be able to run OpenSolaris!
You can roll back to a build 22 via the SVN history. Shouldn't be too hard.
FWIW, there is talk about reinstating sun4m class systems.
The folks doing the PPC/POWER stuff aren't inside Sun, and I don't think they're targetting ancient hardware in any case.