Negroponte might be ok with Microsoft's involvement, but unless they're willing to give it all away for free, OLPC can't actually afford it.
For a system potentially going out to millions of new computer users, and shaping the way those users view all future technology, yes, they probably would give it out for free if necessary. The first hit comes for free.:)
Last time I looked at the Intel driver source, there were a ton of calls into the video BIOS. Not something I would call an "Open Source" driver. This may have changed since then,- I really hope so.
Why is it important to have more source you might ask. Well, for one thing it would be really nice if we can get rid of the video BIOS altogether. A full source driver which shows how to switch video modes is a very good start to accomplish this (although not necessarily enough).
Look into the new "modesetting" branch of the Intel driver, currently moving towards the default. It moves all the work of modesetting and other related hardware manipulation from the video BIOS into the driver, and avoids the video BIOS entirely. This does indeed give the benefits you describe in your post. Some of this modesetting code also moves toward sharing between drivers, to support modesetting for all Xorg video drivers. (Some of it consists of driver-independent code, such as dealing with funky monitors.)
Get your software packaged by Debian (which you probably want to do anyway), and it will get built on (currently) 15 architectures of GNU/Linux, along with 3 non-Linux architectures (kfreebsd-i386, kfreebsd-amd64, hurd-i386), with more popping up occasionally.
No-one seems to have commented on the fact that if NDA requirements are met the drivers cannot be open source. This doesn't mean fewer binary blobs, it means more.
Open Source drivers have been written under NDA before. What this typically means is that they are write-only code. The NDA will prevent things like properly labelling constants and helpful comments, so you end up with code full of magic constants and seemingly random operations. It's basically impossible for anyone to maintain without the NDA'd documentation, so you are pretty much screwed if you want to port it to another OS or maintain it when the original author gets bored or dies.
Some NDAs require that, true; the resulting drivers look a lot like the "nv" driver for X, which does indeed look like write-only code. (And as you suggested, it did still help the authors of nouveau.)
However, in many cases a hardware company NDA just requires non-disclosure of the hardware documentation itself, and in particular the documentation of the hardware's internal workings. In these cases, the resulting driver generally looks like most other drivers in Linux, including useful constants and helpful comments.
(Not commenting on the ethics of NDAs in general; just presenting information.)
Without some kind of censorship how do you know that Blues Clues Holiday Special DVD you just bought for your kids doesn't come with a bonus episode of "Joe Goes Apeshit In A Brothel And Shoots Kittens"?
That doesn't require censorship, just a rating system. Rating systems don't require government assistance, except in the form of laws against fraud (claiming a rating without having it, or making incorrect claims about content). In your example: you know that because you saw the big "G" or "TV-Y" rating logo on the box, and you have some degree of trust that the appearance of that logo occurred legally, because the trademark holders on those logos would sue anyone who used them for content to which they did not apply.
I'm sick of having to launch IE to download a special Linux boot CD because the person hosting it is too lazy to configure their server to serve it with the right Content-Type.
So don't. Right-click on the link and choose "Save Link As...". Or right-click on the ISO-as-text and choose "Save Page As...". Or use wget on the command line. No reason to resort to IE and take advantage of its broken, standards-violating content-type sniffing.
And for the converse case, when someone configures their server to serve up a content type that Firefox wants to download, but you really wanted to view in-browser (like a simple script or patch that you just want to look at), try the Raw Vision extension.
Their test-fires have gone quite well; in addition to testing paraffin/GOX, they've also test-fired salami/GOX, which actually provided more thrust than the paraffin prototype tested that particular day.:)
Before or after Mythbusters did their with salami powered rocket engine?
No, but we did a static test-fire of one. The propulsion team has a test harness, used to fire an engine and measure the thrust without letting it go anywhere. After test-firing a paraffin/GOX prototype, the propulsion team test-fired a salami/GOX "engine" using the same harness. Both engines basically consist of a cylindrical mass of fuel with a cylindrical hole down the middle through which GOX or LOX can flow, though much more care goes into the construction of the paraffin engine.
I work with the Portland State Aerospace Society. We build open source rockets, in every sense of the term: you can find all the details of our work on our site, including software, avionics designs, airframe schematics, and engine/propulsion work. We currently use ammonium perchlorate engines, and we do indeed have to deal with these issues, which prove quite onerous. For this reason, our propulsion team currently has as their primary project the development of a hybrid paraffin and liquid oxygen motor. Both of these components have no regulatory issues whatsoever: the paraffin wax came from a craft store, and the liquid oxygen came from a welding supply store (or with the right equipment, you could make it yourself). Their test-fires have gone quite well; in addition to testing paraffin/GOX, they've also test-fired salami/GOX, which actually provided more thrust than the paraffin prototype tested that particular day.:)
That just leaves us having to deal with any restrictions on active guidance that get thrown our way, which we'll deal with when we finish our active-guidance prototype.
How hard would it be to just have an "Advanced Settings" section in Gnome to give the power users the access to functionality they want.
That already exists; just run gconf-editor, or Applications->System Tools->Configuration Editor if you prefer menus. This gives you access to all the settings that actually exist but don't get exposed. You can also set these on a system-wide basis for all new users, either by editing the system-wide files, or using sabayon (which lets you edit the default settings in an Xnest session).
For settings you want that don't exist, either (in order of preference):
add support for the feature you want in a way that doesn't need a setting (for example, by autodetection)
add support for the feature you want and make a case for changing the default behavior to what you want (which does happen)
add support for the feature you want and add a hidden setting for it which you can tweak via gconf-editor
switch to a different EWMH-compatible window manager or a different application/daemon/tray dohickey, while still using GNOME
switch to a different desktop environment
As for the rest of your post, it sounds like you have support problems caused by different distributions doing things in different ways; I suggest either standardizing on one distribution company-wide (which you can easily do as long as your employees have no preferences amongst them, generally true for most non-computer companies), installing a separately-packaged desktop environment distribution into/usr/local (such as GARNOME), or just living with the differences between distros (generally not that large in this area, just little details as you mentioned).
Debian did not choose this battle. They have been distributing Firefox for years in the same way they distribute other open source software. It was Mozilla who forced the issue by threatening legal action if Debian doesn't change the name or start submitting all patches (even security patches) to Mozilla for permission before they are applied. Mike Conner of Mozilla says "you should consider this, as I previously said, notice that your usage of the trademark is not permitted in this way, and we are expecting a resolution. If your choice is to cease usage of the trademark rather than bend the [Debian Free Software Guidelines] a little, that is your decision to make."
Not only that, but that statement directly revoked the previous standing agreement Debian had with Gervase Markham from Mozilla, which essentially said that Mozilla trusted Debian's (generally conservative) judgement on patches. With this pointed out, Mike Connor confirmed that Gervase did indeed make that agreement, and that Mozilla wished to revoke it.
I understand the Mozilla Foundation/Corporation's issue here, and they certainly have the right to defend their trademarks; that defense itself doesn't necessarily go against Free Software principles. As I understand it, Debian doesn't have any problem with the *trademarks* on the software, because a big build switch exists to turn them on and off; however, Debian *does* have a problem with the non-free copyright license on the images, and thus doesn't use them.
The other problem lies in the fact that Mozilla doesn't really care about the quality of Debian's patches, as much as about getting everyone to use the official releases, regardless of distro policy. They don't like Debian backporting security fixes to 1.0 rather than upgrading people to 1.5, or backporting fixes to 1.5 rather than using Mozilla's (large) point releases; Debian has a "no new upstream versions" policy for stable releases, to avoid breaking things, and many people who run Debian stable rely on that policy.
Of course, this [1] tells me that it, in fact, *is* a i386 machine. So parent is *wrong*:
Yes, gluck, the machine compromised recently, uses x86 hardware. My post responded to someone mentioning the 2003 break-in and claiming the archive server got compromised, while in fact the archive server didn't get compromised because it ran on non-x86 hardware.
first we had the hack into the repository severs, and we didn't know whether or not we are running exploited code when we use apt-get to update our programs.
No, we didn't. The server holding the Debian archive did not succumb to the exploit, because it didn't run on an x86 machine and the people exploiting it only attempted to run x86 code. Furthermore, data on the servers that *did* succumb to the exploit got checked before it became available again.
How about electric companies and water utilities? Or do you see a distinction there too?
Most certainly, since they are also government-granted monopolies, and thus government-regulated.
If such a utility failed to serve a customer, should there not be legal redress?
In addition to the previous point that Google is not a government-granted monopoly, there's also another crucial issue you seem to be missing: Sites in Google's index are not Google's customers. If Kinderstart wanted to be Google's customer, they could pay Google, and get a nice listing on the very first page where it says Sponsored Links. Under those circumstances, Google could certainly be liable for breach of contract if they didn't deliver what they said they'd deliver. But as long as Kinderstart is not a customer of Google, Google has absolutely no obligation to them.
Is this with tv-out and non-mpeg2 sources (ie not dvd, nor from tv-in, but.divx etc)? If yes, you don't happend to know how this is done?
Yes, the PVR-350's TV output works just fine with non-mpeg2 sources. What you want is the "ivtvdev" X Window System driver, which gives you an X server on the PVR-350's TV output, and that X server has Xv support which allows you to play back other video formats with acceleration.
There are several useful ways you could make the MythTV frontend and the X server start on boot and stay running; I just put it in/etc/inittab:
"TV" is a layout in my X server configuration which uses ivtvdev. This approach seemed far simpler and more lightweight than many people's suggested solution of running full-blown KDM and KDE, setting KDM to auto-login as mythtv, and creating an autostart.desktop file for MythTV. YMMV.
Buy a Hauppauge PVR-350. It includes TV-in with MPEG2 encoding, TV-out with MPEG2 decoding or with full Xv support, and a nice remote control which works perfectly with LIRC and MythTV.
If you want additional tuners later, I recommend getting a PVR-500; two tuners with MPEG2 encoding in one PCI card.
No; this draft includes specific language handling that case: "a code need not be included in cases where use of the work normally implies the user already has it." In other words, this only covers cases where you don't have the key, such as devices which check signatures on their firmware binaries.
There is no useful purpose for a technology designed to "protect" a machine from its owner.
Online gamers who suffer from cheaters would disagree. Movie producers who have a $10 million film to finance and want to make it available for download would also disagree.
So I've heard. In both cases, the technology is being used to restrict the use of a computer against the wishes of its owner. Cheaters (in multiplayer games) are scum, but so are games which want to put tentacles throughout your system to monitor them; and in any case, the only sure way to prevent most cheating is to move all the relevant logic server-side, which solves all cheating problems other than bots. As for films available for download, I have every right to do whatever I want with such films as long as I don't give them to anyone else; DRM (TCPA-enabled or not) won't let me do anything the producers didn't anticipate, like putting it on my MythTV box, or on a video iPod or Neuros.
People are so paranoid about TCPA, it's funny. Hello people, go read the specs like I did. You'll come away with a different impression.
I already have; every last word of it. My impression has only grown stronger with being better informed.
The TPM chip is a tool just like encryption is. Like encryption it can be used for both bad and good. Just like PGP can protect criminal communication as easily as it protects commerce, the TPM can be used in many ways.
Everything the TPM can do falls into two categories: the things you could *already* do without needing hardware (which are perfectly fine to support in hardware; I like the idea of hardware-accelerated crypto), and the things that have no purpose other than restricting the owner of a machine.
Let's clear up a few misconceptions:
No, the TPM cannot stop you booting Debian. That's a dumb idea based on zero knowledge of what the technology does.
Very true, and I endeavor to correct that misconception when I see or hear it.
Yes, it can stop you accessing certain content if you are running Debian, because the TPM prevents you from lying about the configuration of your computer.
Exactly; remote attestation is the main issue with TCPA, since it is the only one that affects someone who chooses to opt out of using it. Everything else only affects those who don't control the software which runs on their computer, but remote attestation affects those who *don't* use such software and/or hardware. Every indication from the supports of TCPA is that this is the intent: to be able to ask a system to report its true configuration or not report anything at all, preventing any possibility of a different-but-compatible implementation.
If the content provider (online music store or whatever) doesn't want you use Linux to access their content, tough cookies. But this already happens today: there are no DRM implementations for Linux and the only way to play back music bought from iTMS is to either run iTunes under Wine or strip the encryption. And that's only possible because FairPlay is not a terribly good implementation of DRM - try playing back music bought from the Yahoo! Music Store, which uses Windows Media and you'll find you can't.
First, note that there is yet another way to avoid it: just use SharpMusique, which doesn't put the DRM on it in the first place. Second, note that DRM is not the issue here, since it can already be done without needing TCPA (just not as effectively). The real issue is the ability to even talk to the store in the first place with a client that the server doesn't expect. The Free Software community has been excellent at creating *compatible* implementations of protocols even without documentation or cooperation; consider Samba for example, which TCPA could easily be u
This is simply a marketing tactic to attempt to gain acceptance for a technology designed to get humans out of the loop whether they like it or not. There is no useful purpose for a technology designed to "protect" a machine from its owner. This marketing tactic simply tries to propose the "but what if we're trying to protect the owner from their own stupidity" angle; however, that kind of thing could be done in software as well.
You might also try just finding out which companies are in the Oregon area and looking at their jobs pages to see if they have jobs in the area.
Some of the notable large employers in Oregon include Google, Intel, IBM, and HP. There are also a huge number of smaller companies in Oregon if you prefer that type of environment.
Much like Common Vulnerabilities & Exposures (
on
Name That Worm
·
· Score: 1
This project is likely intended to do for viruses, spyware, and other malicious programs what CERT's existing Common Vulnerabilities and Exposures (CVE) does for security issues. CVE has attained widespread acceptance for use in unique and unambiguous identification of security issues; hopefully this project will have the same level of success.
Get the Anti-Pagination extension for Firefox, right-click on the Next link, choose Anti-Pagination->All, and scroll through the complete content without clicking another link.
The biggest difference is that if you contribute and distribute your changes to an (L)GPL project, you must make your source publicly available. Under the SISSL, you could distribute binary-only versions of the project.
While it is true that the SISSL allowed binary-only distributions, it allowed them only if you provided documentation of any changes that you made to file formats or other standardized items. This is still a Free license, because full source code is considered sufficient documentation, so it's essentially a copyleft with an exception for software which documents its deviations from standards.
Slashdot Mirror
For a system potentially going out to millions of new computer users, and shaping the way those users view all future technology, yes, they probably would give it out for free if necessary. The first hit comes for free.
Or Silicon Forest, particularly if you want to work on Free and Open Source Software.
Look into the new "modesetting" branch of the Intel driver, currently moving towards the default. It moves all the work of modesetting and other related hardware manipulation from the video BIOS into the driver, and avoids the video BIOS entirely. This does indeed give the benefits you describe in your post. Some of this modesetting code also moves toward sharing between drivers, to support modesetting for all Xorg video drivers. (Some of it consists of driver-independent code, such as dealing with funky monitors.)
Get your software packaged by Debian (which you probably want to do anyway), and it will get built on (currently) 15 architectures of GNU/Linux, along with 3 non-Linux architectures (kfreebsd-i386, kfreebsd-amd64, hurd-i386), with more popping up occasionally.
However, in many cases a hardware company NDA just requires non-disclosure of the hardware documentation itself, and in particular the documentation of the hardware's internal workings. In these cases, the resulting driver generally looks like most other drivers in Linux, including useful constants and helpful comments.
(Not commenting on the ethics of NDAs in general; just presenting information.)
That doesn't require censorship, just a rating system. Rating systems don't require government assistance, except in the form of laws against fraud (claiming a rating without having it, or making incorrect claims about content). In your example: you know that because you saw the big "G" or "TV-Y" rating logo on the box, and you have some degree of trust that the appearance of that logo occurred legally, because the trademark holders on those logos would sue anyone who used them for content to which they did not apply.
So don't. Right-click on the link and choose "Save Link As...". Or right-click on the ISO-as-text and choose "Save Page As...". Or use wget on the command line. No reason to resort to IE and take advantage of its broken, standards-violating content-type sniffing.
And for the converse case, when someone configures their server to serve up a content type that Firefox wants to download, but you really wanted to view in-browser (like a simple script or patch that you just want to look at), try the Raw Vision extension.
Well before. Mythbusters revisited the confederate rocket myth with a salami rocket on April 26, 2006, whereas we test-fired a salami on September 11, 2004 in the Black Rock Desert of Nevada.
No, but we did a static test-fire of one. The propulsion team has a test harness, used to fire an engine and measure the thrust without letting it go anywhere. After test-firing a paraffin/GOX prototype, the propulsion team test-fired a salami/GOX "engine" using the same harness. Both engines basically consist of a cylindrical mass of fuel with a cylindrical hole down the middle through which GOX or LOX can flow, though much more care goes into the construction of the paraffin engine.
I work with the Portland State Aerospace Society. We build open source rockets, in every sense of the term: you can find all the details of our work on our site, including software, avionics designs, airframe schematics, and engine/propulsion work. We currently use ammonium perchlorate engines, and we do indeed have to deal with these issues, which prove quite onerous. For this reason, our propulsion team currently has as their primary project the development of a hybrid paraffin and liquid oxygen motor. Both of these components have no regulatory issues whatsoever: the paraffin wax came from a craft store, and the liquid oxygen came from a welding supply store (or with the right equipment, you could make it yourself). Their test-fires have gone quite well; in addition to testing paraffin/GOX, they've also test-fired salami/GOX, which actually provided more thrust than the paraffin prototype tested that particular day. :)
That just leaves us having to deal with any restrictions on active guidance that get thrown our way, which we'll deal with when we finish our active-guidance prototype.
That already exists; just run gconf-editor, or Applications->System Tools->Configuration Editor if you prefer menus. This gives you access to all the settings that actually exist but don't get exposed. You can also set these on a system-wide basis for all new users, either by editing the system-wide files, or using sabayon (which lets you edit the default settings in an Xnest session).
For settings you want that don't exist, either (in order of preference):
As for the rest of your post, it sounds like you have support problems caused by different distributions doing things in different ways; I suggest either standardizing on one distribution company-wide (which you can easily do as long as your employees have no preferences amongst them, generally true for most non-computer companies), installing a separately-packaged desktop environment distribution into
Not only that, but that statement directly revoked the previous standing agreement Debian had with Gervase Markham from Mozilla, which essentially said that Mozilla trusted Debian's (generally conservative) judgement on patches. With this pointed out, Mike Connor confirmed that Gervase did indeed make that agreement, and that Mozilla wished to revoke it.
I understand the Mozilla Foundation/Corporation's issue here, and they certainly have the right to defend their trademarks; that defense itself doesn't necessarily go against Free Software principles. As I understand it, Debian doesn't have any problem with the *trademarks* on the software, because a big build switch exists to turn them on and off; however, Debian *does* have a problem with the non-free copyright license on the images, and thus doesn't use them.
The other problem lies in the fact that Mozilla doesn't really care about the quality of Debian's patches, as much as about getting everyone to use the official releases, regardless of distro policy. They don't like Debian backporting security fixes to 1.0 rather than upgrading people to 1.5, or backporting fixes to 1.5 rather than using Mozilla's (large) point releases; Debian has a "no new upstream versions" policy for stable releases, to avoid breaking things, and many people who run Debian stable rely on that policy.
No, we didn't. The server holding the Debian archive did not succumb to the exploit, because it didn't run on an x86 machine and the people exploiting it only attempted to run x86 code. Furthermore, data on the servers that *did* succumb to the exploit got checked before it became available again.
Or when you spam all the people spammers use as their forged From addresses.
In addition to the previous point that Google is not a government-granted monopoly, there's also another crucial issue you seem to be missing: Sites in Google's index are not Google's customers. If Kinderstart wanted to be Google's customer, they could pay Google, and get a nice listing on the very first page where it says Sponsored Links. Under those circumstances, Google could certainly be liable for breach of contract if they didn't deliver what they said they'd deliver. But as long as Kinderstart is not a customer of Google, Google has absolutely no obligation to them.
Yes, the PVR-350's TV output works just fine with non-mpeg2 sources. What you want is the "ivtvdev" X Window System driver, which gives you an X server on the PVR-350's TV output, and that X server has Xv support which allows you to play back other video formats with acceleration.
There are several useful ways you could make the MythTV frontend and the X server start on boot and stay running; I just put it in
This approach seemed far simpler and more lightweight than many people's suggested solution of running full-blown KDM and KDE, setting KDM to auto-login as mythtv, and creating an autostart
Buy a Hauppauge PVR-350. It includes TV-in with MPEG2 encoding, TV-out with MPEG2 decoding or with full Xv support, and a nice remote control which works perfectly with LIRC and MythTV.
If you want additional tuners later, I recommend getting a PVR-500; two tuners with MPEG2 encoding in one PCI card.
No; this draft includes specific language handling that case: "a code need not be included in cases where use of the work normally implies the user already has it." In other words, this only covers cases where you don't have the key, such as devices which check signatures on their firmware binaries.
So I've heard. In both cases, the technology is being used to restrict the use of a computer against the wishes of its owner. Cheaters (in multiplayer games) are scum, but so are games which want to put tentacles throughout your system to monitor them; and in any case, the only sure way to prevent most cheating is to move all the relevant logic server-side, which solves all cheating problems other than bots. As for films available for download, I have every right to do whatever I want with such films as long as I don't give them to anyone else; DRM (TCPA-enabled or not) won't let me do anything the producers didn't anticipate, like putting it on my MythTV box, or on a video iPod or Neuros.
I already have; every last word of it. My impression has only grown stronger with being better informed.
Everything the TPM can do falls into two categories: the things you could *already* do without needing hardware (which are perfectly fine to support in hardware; I like the idea of hardware-accelerated crypto), and the things that have no purpose other than restricting the owner of a machine.
Very true, and I endeavor to correct that misconception when I see or hear it.
Exactly; remote attestation is the main issue with TCPA, since it is the only one that affects someone who chooses to opt out of using it. Everything else only affects those who don't control the software which runs on their computer, but remote attestation affects those who *don't* use such software and/or hardware. Every indication from the supports of TCPA is that this is the intent: to be able to ask a system to report its true configuration or not report anything at all, preventing any possibility of a different-but-compatible implementation.
First, note that there is yet another way to avoid it: just use SharpMusique, which doesn't put the DRM on it in the first place. Second, note that DRM is not the issue here, since it can already be done without needing TCPA (just not as effectively). The real issue is the ability to even talk to the store in the first place with a client that the server doesn't expect. The Free Software community has been excellent at creating *compatible* implementations of protocols even without documentation or cooperation; consider Samba for example, which TCPA could easily be u
This is simply a marketing tactic to attempt to gain acceptance for a technology designed to get humans out of the loop whether they like it or not. There is no useful purpose for a technology designed to "protect" a machine from its owner. This marketing tactic simply tries to propose the "but what if we're trying to protect the owner from their own stupidity" angle; however, that kind of thing could be done in software as well.
A few I know of are Jobdango and Oregon Live's jobs page. The former is likely more useful than the latter.
You might also try just finding out which companies are in the Oregon area and looking at their jobs pages to see if they have jobs in the area.
Some of the notable large employers in Oregon include Google, Intel, IBM, and HP. There are also a huge number of smaller companies in Oregon if you prefer that type of environment.
This project is likely intended to do for viruses, spyware, and other malicious programs what CERT's existing Common Vulnerabilities and Exposures (CVE) does for security issues. CVE has attained widespread acceptance for use in unique and unambiguous identification of security issues; hopefully this project will have the same level of success.
Get the Anti-Pagination extension for Firefox, right-click on the Next link, choose Anti-Pagination->All, and scroll through the complete content without clicking another link.