Apt does feature an unattended-upgrades mode. It's not the default, which is annoying, but it's pretty easy to configure. It's one of the first things I configure on a new Debian box.
As for outdated packages: Debian unstable and experimental usually contain cutting and bleeding-edge versions of most open source software that is packaged in Debian. Unlike the grandparent poster, I would not recommend running sid (AKA unstable) as my main repository, because doing an apt-get upgrade has occasionally wrecked my system on sid. I use Linux Mint Debian Edition, which is based on regular tested snapshots of testing, but I do occasionally need cutting-edge packages. I would recommend looking into apt preferences, which provides a nice way to grab specific cutting-edge packages from unstable and experimental while dragging in a minimal number of unstable dependencies. So far I have had almost no problems doing this, and certainly far fewer problems than using 3rd party repositories.
I'm quite happy with Linux Mint Debian Edition. It provides a nice middle ground between stable-but-out-of-date-and-highly-political Debian and unstable-but-nice-features Ubuntu. LMDE is basically a tested snapshot of Debian testing (like CUT was supposed to be, but actually regularly maintained) with a lot of the ease-of-use features (proprietary drivers, etc) of Ubuntu. Unlike Ubuntu or regular Linux Mint (which is based on Ubuntu), LMDE is completely compatible with Debian. I can use the apt preferences mechanism to pull in some more recent packages from Debian unstable and experimental, more or less seamlessly.
Both the MATE and Cinnamon editions of LMDE are good, depending on your GUI preferences. MATE seems a bit more mature, but it's definitely old technology. Cinnamon provides modern compositing coolness, and has been making some huge improvements, but it's still rough around the edges with respect to some of the GUI configuration screens.
They just cut the new ISOs a few days ago, so the packages on them are fresh.
I agree with the parent that quality control is a problem with all new CFLs, and disagree that it is merely a matter of household electrical quality. I made the switch to CFLs throughout most of my apartment way back in 2002. I did it because my overhead lighting sockets were inconvenient to replace, and I was replacing incandescents on average one every 2 months. I bought some Phillips (or Sylvania? I don't remember) 32-watt bulbs that emitted the lighting equivalent of 120-watt incandescents. They were expensive at the time, but they worked beautifully: bright light, perfect color, and no flicker. All 9 of them kept working for well over the rated lifetime; 2 of them still are. I was very impressed and encouraged friends and family to switch.
Fast forward to last year. The bulbs eventually began to show signs of dying: flickering when turned on, and black charring around the bases of the bulbs. Over a period of months, they died and I bought some new replacement 23-watt 100-watt equivalent CFLs, from Phillips and Sylvania. Of the 7 replacements I purchased in the last year, so far 3 of them have failed, and another is showing signs of failing. Furthermore, every now and again I can detect a bit of flicker from the new bulbs, but still none from the old ones. For each failure, I have complained and gotten a coupon for a new bulb, but it's annoying and inconvenient, and it's put me in the same place as with incandescents regarding frequent replacement.
I don't believe that I have electrical problems in my apartment. These new bulbs are plugged into the same sockets that the old ones used, and 2 of the old ones still use. Furthermore, I have SmartUPSs attached to my computers and monitor their logs, and they *very* rarely record a power-related event. The power grid where I live is stable.
My conclusion is that, like most things in the business world, in the early years of CFLs, corporations put out the best product possible to gain market acceptance. Now that the market has shifted and CFLs have gained acceptance, I think that corporations are cutting corners and cutting costs to maximize short-term profits, and if this means a higher failure rates, then that's just another cost to be balanced on their books.
I hate to reply to my own posts, but I just thought of an additional comment to add.
In the example of the picture frame, likely all of the extra Wi-Fi Direct magic will be baked into the firmware.
On the other hand, for devices like laptops, I doubt that they would put this amount of software into firmware. It is likely that the extra components that turn plain Wi-Fi into Wi-Fi Direct will be entirely software that is delivered by a package of drivers and helper programs that are all provided by the OS or via a setup disc. This sort of of all-in-one setup will likely be offered to Windows and Mac users. However, users of independent operating systems, like Linux, will likely not see this, and will likely still have to manually setup these subsystems. Therefore, for Linux users, I imagine that we will see no real difference at all between a plain Wi-Fi chipset and a Wi-Fi Direct chipset.
According to Wikipedia, Wi-Fi Direct is ad-hoc mode Wi-Fi device with a built-in Wi-Fi Protected Access setup daemon, optional access point software (e.g., routing to other networks) and an as-yet undefined service discovery mechanism (e.g., UPnP, Bonjour). Basically, they are writing a standard which ties together several existing standards and best practices. This sort of meta-standard is quite common.
One example they give is a picture frame, which offers only the required ad-hoc mode Wi-Fi and Wi-Fi Protected Access daemon, and a simple service for file upload. The user would connect to it, upload pictures, and then disconnect. Nothing else would be offered by the frame, but the user would not need to do any manual setup or buy any additional devices.
A more complicated example is a cell phone which offers tethering. In addition to the required ad-hoc mode Wi-Fi and Wi-Fi Protected Access daemon, has full blown bridging/routing and service discovery daemons built-in. The user would expect to treat this device more like an infrastructure mode network in a single package; perhaps some setup would be required on the Wi-Fi Direct device, but virtually no additional setup would be required on each connected device.
So basically they are just making a standard, the implementation of which requires doing all of the things we have done manually for our own networks. This is just one step further in simplifying network setup, but not any kind of new revolution.
0) By "greatly improves the performance" do you mean by some order of magnitude, or merely by a constant factor? For example, are you going from O(n^2) to O(n log n), or is it only O(10n) to O(5n). Don't get me wrong, the latter can be useful, but the former would draw more attention from the research community. I assume you know Big-O notation and formal analysis of algorithms, otherwise you will need to learn about it before submitting a research paper in algorithms.
1) If you have never even read a full research paper, then how do you know your approach is new or better than existing approaches? First, I would recommend getting a data structures and algorithms book and a computational geometry book. Read through those looking not only for things similar to your technique, but also just to make sure you have the vocabulary correct. Then move on to Google Scholar and start looking into the more recent scholarly journals and conference proceedings on the topic. You will need subscriptions (probably via a university) to see a lot of that content, but you can try the "All X versions" link beneath most articles to see if the author published a PDF on a public web site. Books are usually years behind the state of the art, and a lot of newer research and algorithms only fully appears in papers. Also, a lot of research (most?) is not published on blogs, so your algorithm may not be as new or groundbreaking as you think. Or if it is, you still may find more inspiration to improve it from related techniques.
2) Ditto what others have said about learning LaTeX for page layout. However, if you might want to publish in a specific journal or conference, then you might have to use their specific format, so you might just want to type your first draft as plain text and a collection of images, for import into a specific LaTeX template later.
3) Writing style: You must be *very* *formal* in your writing style to be considered credible in academic circles. Have an English teacher (or similarly-minded person) go over the paper with a fine-toothed comb looking for any spelling, grammar, or word-use errors. Absolutely no slang or colloquialisms whatsoever are acceptable in a research paper. Do not use contractions. Try not to use any analogies unless they are truly apt and likely to be universally understood. Try not to use first or second person in the paper. Remember, people from all over the world from different cultures, many of whom do not speak English as their primary language, will hopefully be reading your paper, and you don't want them to get confused by any culture-specific concepts or words.
4) If your algorithm really is new or groundbreaking, then I would strongly recommend trying to publish in a proper academic workshop or conference first (try ACM or IEEE conferences on computational geometry, location-driven computing, etc.), rather than a free online archive. You will get far more credibility and exposure in academia, and you just might get your employer to pay for a junket to a conference! Workshops are more for newer, less developed research, so you may have an easier time publishing there. Conferences are for more established research, so it's harder to get in them, but they carry much more respect. Also, most workshops and conferences have industrial tracks, if your paper focuses less on formal algorithmic analysis and more on real-world uses.
5) Be warned though, that although conferences are supposed to be submitter-blind, often it's much easier to get a publication when you have a known academic co-author on the paper. You might want to look up authors of papers related to yours, find the Ph.D.s on the paper, and approach them about a collaboration. This might take a bit more time, and you would have to share credit (just make sure you are first-author), but it may be worthwhile to get more exposure and credibility. They might also be able to help point you toward making further improvements to your algorithm.
6) Please, please, do not patent your algorithm! There is more than enough patented math already; the world does not need yet another algorithm that can't be used by anyone for 20 years.
Take it from someone who owned one: the OpenMoko was a terrible phone and a terrible handheld computer. It was nearly useless when not hooked up to a computer via SSH over USB. OpenMoko earned an A for vision in getting a fully open and documented hardware interface, although the results were dubious (crappy GPRS GSM modem in an era when 3G was just becoming popular, crappy non-accelerated drivers for the video chipset). However, OpenMoko's worst failing was the total inability of the company to push a singular stable and complete platform for development; there were about 20 different incompatible distributions in various states of disarray, and you cannot have a platform for end-user app development in that sort of environment. (Imagine how unsuccessful Apple's app store or Android's marketplace would be if developers and users had to choose between 20 different incompatible distributions, all in permanent alpha status...) I think I can live with a few proprietary blobs if it means having a useful device. All of the open technology in the world means nothing if the platform dies on the vine before ever taking off. OpenMoko's ideal of a fully open phone platform proved unsustainable, as the company canceled their "next-gen" (translation: 2.5G in an era of 3G) phone and switched to producing a ridiculous "WikiReader" device which contains no pesky radio or accelerated video modules.
After more than a year of trying to use it, I finally was overjoyed to get rid of my crappy Freerunner. On the other hand, even though my N800 does not have a cell radio, I still like to use it, and am strongly considering buying an N900. I think the OpenMoko was for people who love putting together distributions and blogging about how much freer their device is compared to everyone elses'. A platform like the N800/900 is for people who like programming mobile computers to accomplish useful tasks and then distributing those programs to non-programmers.
I don't know what the protocol is for civil litigation, so I do not know whether some officer would seize your equipment at the time of service of litigation, as happens in criminal matters.
But assuming that you are able to retain control of your machines and autonomy in their use for some time after being served, then it would actually be quite difficult to securely wipe them and reinstall them without leaving behind some evidence that could be discovered by a forensics expert. Other posts in this thread do a good job of going into detail about specific ways of telling that such a wiping happened, such as looking for evidence of massive patching, or unusually large timestamp jumps. If you are caught, which is likely, then even assuming that you are not subject to criminal penalties for evidence tampering, you can still be nailed by a default judgment against you in the civil matter (where the evidence has merely to be more likely than not, rather than beyond a reasonable doubt).
So, trying to wipe a drive is a losing strategy.
Your best bet to handle this situation requires some fore-planning and regular updating of planning. You must have a brand new hard drive available *before* you get served. Them your best bet is, assuming you retain control of your computer for some time, to *immediately* remove your hard drive and destroy it, and replace it with a brand new hard drive. Then you claim in your affidavit in response to request for discovery that your old hard drive died *before* you were served, and you destroyed the old hard drive *before* you were served. You have to have bought the new hard drive *before* you were served, because they can track when the hard drive was manufactured and possibly even sold, and if the records say it was sold *after* you were served, you get nailed for perjury. Also, the hard drive should be reasonably recent, as one would be unlikely to install a 5 year old "new" hard drive in case of a failure, rather than buying a newer hard drive at the time of failure. Note that some forensics analyses can identify a specific instance of an operating system install based solely on network port scans and other traffic analysis; even though it is currently unlikely that the opponent would have used such a scan on you before serving you, to protect yourself against potential proof that your operating system instance remained the same up until the time of discovery, you should *always* have a hardware firewall between your computer and the Internet.
Of course, the above paragraph details a theoretical method to attempt to subvert the legal system. I do not support perjury and my advice to you is to not to tamper with evidence or lie about evidence.
Minor point of interest - OpenMoko is the software company, AFAICT, and FIC are the hardware company.
I don't know if that is an accurate statement.
FIC is definitely the hardware manufacturer, but OpenMoko seems to be responsible for a significant portion, if not all, of the hardware design for the OpenMoko phones. (At least, this is what I glean from mailing lists where OpenMoko employees discuss the development of hardware revisions.) This would put them squarely in the hardware company category.
Furthermore, OpenMoko has said or implied that their primary software responsibilities are to write drivers for low level hardware, and to provide basic utilities for testing the hardware. It seems that they have more or less pushed the responsibility of creating a stable application development platform, AKA distribution, to the ephemeral "community".
The abdication of the development of a singular, stable, comprehensive platform for application development was a strategic blunder of monumental proportions that will ultimately be fatal to the company. In the absence of a single platform, the Free Software community has done what it naturally does: fragments. No serious mobile application developers will target the OpenMoko, because there does not exist one stable, comprehensive API that is guaranteed to exist on all phones. (Note: I am not advocating that no one else should be allowed to provide an alternative distribution, or that the official distribution should be closed-source; I advocate that OpenMoko should have allocated the necessary resources to ensure that there would exist one stable, usable, and comprehensive platform, before the first phones ever shipped to the general public.)
In the absence of a single platform, we have many competing platforms such as Gnome Mobile, home-rolled FSO, various partially incompatible versions of Trolltech Qtopia, and a seriously hacked-up Android derivative. On top of that are many competing GUI libraries, such as GTK, QT, Enlightenment, and others. What does a developer target to target all OpenMoko phones? Already, many distributions include all libraries; this is wasteful on a device with only 256MB of built-in storage. What does a developer do to make sure his app fits in thematically with the rest of the phone? There is nothing that can be done, with so many different competing GUI libraries with incompatible widget sets and theming mechanisms. OpenMoko apps look and feel like a Chimera, the mythical Greek monster made of an assortment of animals.
OpenMoko still lacks basic features such as a usable on-screen keyboard (none of the alternatives are particularly good), a usable web browser (once again, many options, none particularly good) and a usable email client. In general, we lack most apps in finger-friendly format. Note to OpenMoko developers: I DO NOT WANT to carry around a stylus with my phone. Furthermore, there is no proper centralized repository (opkg.org is close, but not a real repository), unless you use a Debian distribution, in which case you've got a whole raft of usability problems. In many cases, you have to download important applications from some random hacker's website in Russia (GPRS). And there is no digital signatures mechanism currently being used by anyone that I am aware of, so I have no idea if any of the software I download has been trojaned.
The purported advantage of the OpenMoko design over Android was the native support for X11; I was at first convinced that this was awesome, because "existing GNU/Linux apps could be ported in no time". However, I have seen what most "ports" consist of: dumping the app onto the phone with little or no GUI changes. The OpenMoko screen is 480x640, and the overwhelming majority of X11 apps are no longer are designed to work at this scale. Often, with dumped apps, I find that critical GUI elements are off-screen, with no known way to get to them. Even when the GUI fits onto the sc
As others have mentioned, `xhost +` is unnecessary in this scenario and potentially harmful.
Also, X is a bit painful to use over slow and/or high-latency connections. For this, you may want to set up FreeNX. Once setup, it works similarly to X, only optimized for low-speed high-latency connections.
The end result is the old adage I first heard applied to the Chicago political machine of the 1960s: A government does not have to be good, and rarely is. It only has to be good enough that the populace will tolerate it.
An older version of the same adage:
Prudence, indeed, will dictate that Governments long established should not be changed for light and transient causes; and accordingly all experience hath shewn that mankind are more disposed to suffer, while evils are sufferable than to right themselves by abolishing the forms to which they are accustomed. But when a long train of abuses and usurpations, pursuing invariably the same Object evinces a design to reduce them under absolute Despotism, it is their right, it is their duty, to throw off such Government, and to provide new Guards for their future security.
The last time I installed using LVM, you still needed a separate/boot partition. Maybe that's changed, though.
I used to use LVM religiously. I still love its ability to resize partitions. However, when anything goes wrong with the filesystem, it's really, really painful to try to fix it. I finally quit using LVM because of that.
Gather old computer parts from your school or lbusiness (sic), put them together, install linux and give them to schools with limited computing resources.
Most people not involved don't know this, but trying to donate to public schools can be incredibly frustrating, at least in parts of the US and especially in urban areas. Public school bureaucracy can be stifling. I have some friends who have worked with Techserv at Drexel University in Philadelphia. I have seen poor inner-city schools with almost no computers and no budget spend months or longer going through "proper channels" just to accept a donated computer. I naively thought that they would just accept them under the table but no, they have to go through the bureaucracy. Here in Philadelphia we have plenty of schools that need computers, but last I checked, Techserv has a large storage room packed with good hardware that they have trouble giving away.
Not that it is not worth doing. Just be prepared for some hair-pulling frustration and have plenty of storage space.
According to LotR, cruelty, malice and a will to dominate all life were its primary ingredients. Yup, sounds like the perfect ingredients for a successful marriage.
There was one realtime 3D map in the lobby area of the 18th floor, right in front of Turing. It was definitely there Sunday, and I think it might have been there at least part of Saturday, too. There might have been another one on the mezzanine, but I don't specifically remember it.
Did you sue? I sure as hell would have. The only thing that is going to stop this madness is for everyone these things happen to sue. And don't just go for medical bills. File for unspecified punitive damages for the mental anguish you went through almost losing your [lw]ife.
With the event you described, any decent ambulance chaser would take the case and negotiate a settlement, and the business will likely settle for an amount just less than their projected cost to win at trial. The lawyer will take most of that, so you won't end up with much. Nevertheless, if this happens often enough, the corporation will learn a lesson.
As much as I hate the way this country has become one big lawsuit factory, nowadays (often silly) personal injury lawsuits are often the only way to effect change in corporate cheapness.
Your response misinterprets the termination provision (Section 8) of GPLv3-draft2. I can see how you could reach that misinterpretation with draft 1, but draft 2 makes that interpretation baseless.
You have to go BUY one my appliances, which can be a significant outlay of money, then investigate it carefully, a significant outlay of your valuable time, before you can even be certain I did use your code.
This part is a red herring. The same is true for GPLv2. Do you think copyright violations go away magically because they are violations? No, they require the copyright holder to first notice the violation, including collecting some sort of evidence of genuine violation, then commence some sort of legal action, usually involving the sending of a cease and desist notice.
You're in the hole here, and you still have to give me 60 days to come into compliance before you can terminate the license and have any leverage at all with me.
Substantially incorrect. I quote from GPLv3-draft2 Section 8. Emphasis is mine:
You may not propagate or modify the Program except as expressly provided under this License. Any attempt otherwise to propagate or modify the Program is void. If you violate this License, any copyright holder may put you on notice by notifying you of the violation, by any reasonable means, provided 60 days have not elapsed since the last violation. Having put you on notice, the copyright holder may then terminate your license at any time. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as they remain in full compliance.
It is very simply stated and unambiguous. If the copyright holder notices current, ongoing violation then obviously 60 days have not yet passed since the last violation, as the violation is happening currently. Thus, the copyright holder is within his rights to put the violator on notice. Having put the violator on notice, if the violation is not corrected promptly, the copyright holder may then terminate the license at any time. There is no requirement in the language for the copyright holder to wait some specified period of time after noticing infringement before he acts. He is free to act immediately once he notices the infringement.
I suspect you did not notice the "not" in the clause "...provided 60 days have not elapsed...". That would explain your apparent confusion.
The one really scary clause in v3 seems to be the one that everyone overlooks. The license termination clause looks rather toothless in comparison to GPL2, and, outside of the guy that runs the GPL violations web site, no one seems to be paying much attention to that.
The draft 2 clarification seems to make it better. The license says that the copyright holder has 60 days from the date of last violation to put the violator on notice. In cases of accidental violation, this means that if you fix the violation, a copyright holder can't come along 2 years later and say, "You were non-compliant 2 years ago, so your license terminated." Under the GPLv2, that situation could potentially happen (although to my knowledge, it hasn't yet).
In situations of continual and/or deliberate violation, the 60 day limit would by definition be a rolling deadline, so the copyright holder could notify the violator, then terminate the license accordingly. The provision for termination under this case certainly is not "toothless".
I don't see how this differs significantly from the GPLv2. It just provides a little shield for distributors who accidentally violated the GPL, but then fixed their violation and stayed clean afterward.
Oh, joy. Now, when trying to use multiple open source projects, we can't even assume that two GPLv3 projects have compatible licenses. "libAardvark is GPLv3 with restrictions 4, 7, and 19, and gLlamaBoy is GPLv3 with restrictions 1, 8, and 21-36. We'll have to rewrite one of them."
Remember, any GPLvX code can automatically be linked to any other GPLvX code (although not necessarily to GPLvX-1 code). The allowable optional restrictions of section 7b do not impose contradictory burdens (that is, option 2 does not contradict option 3, etc) nor do they really add significant burdens to the vanilla GPLv3 (with the exception of 7.b.4 which is the web services option and the one everyone is still up in arms about). They are just minor differences in effect and the purpose of Section 7 is to allow modules with such minor licensing differences to be linked.
In fact, not only is the purpose of this section to allow you to link code under all permutations of the GPLv3, it also allows you to link GPLv3 code to various Free Software licenses that were not previously linkable due to minor wording differences or patent retaliation clauses. In fact, the controversial 7.b.4 section was to allow linking with the Affero Free Public License. The big debate should not just be whether 7.b.4 is okay, but also whether the Affero Free Public License is really a Free license.
One of the things that was discussed regarding the GPL v3 was adding a provision that made web services considered distribution that would require eleasing [sic] the source as per the GPL...
The short story is that this definition of distribution (distribution is now called "conveying" in license language) has been rejected by the FSF and does not appear by default in this draft of GPL3.
The longer story: Some web services projects do want to include a link to allow users to download source, and they do want to limit server administrators from removing this capability. To appease this group, the FSF has added an optional license provision that forbids removal of such a feature. I repeat, this is an optional license feature that takes effect if and only if a given project explicitly activates it.
I suspect that you are right and that most web service providers will not want to use up resources with users downloading web service source. So, I suspect that the market will cause any such projects to diminish in popularity. The important thing to note is that the FSF is not forcing this notion of distribution on any project using the GPLv3.
On a related note, the GPLv3 drafts Section 7b contains a list of optional license restrictions (including the above mentioned restriction) that are permissible. All of these restrictions are things that the FSF does not believe are necessary to maintain a Free program, but that the FSF acknowledges won't seriously harm user freedom if individual projects choose to activate them. Mostly, this list is provided to improve the GPLv3's compatibility with other Free Software licenses which contain equivalent restrictions but are incompatible with GPLv2. This attempt at license compatibility with other Free Software licenses is a big improvement for the GPL.
For example using DRM to protect your personal information that is in the hands of a large corporation or government. Just think about the ability to turn on and turn off the access to your ID and personal info, based on who looks at it, not just based on who copied it out of one database and into another. Think about moving from one cell phone company to another, and when they get down to your record in the database all they see is random noise, because they no longer have the DRM to your phone number and can't call you.
It won't ever happen. Ever. All the phone companies (and every other company and government) will require you to provide your information in a non-restricted format.
An entity can only roll out data restrictions if it has a power relationship over the data's consumers. For example, an RIAA label can force you to accept a restricted song, because it is the only "legal" provider of that song. On the other hand, you the individual consumer mean nothing to a corporation, as there are millions of others like you.
In theory, companies could be forced to accept a restricted format if a large percentage of their customers cooperated in a boycott unless and until the restriction was accepted. (Good luck dealing with governments.) Experience has shown that average people don't care about privacy issues enough to go through the inconvenience of a boycott.
One thing that the current situation has taught us is that if there is a legitimate way for an entity to get non-restricted data, the non-restricted data will proliferate at the expense of the restricted data. DRM only works if there is no non-restricted equivalent. As so many corporations and governments will force you to give away your non-restricted data, that data will proliferate through the society, just as it does now.
DRM is ultimately infeasible for the average individual. Each person would need to have a server online at all times, permitting or denying access requests. High security would be needed, otherwise entities would just break in and give themselves whatever permissions they want. Uptime and connectivity would also be strict requirements, otherwise legitimate uses of data would be blocked pending approval. (Or imagine the malicious failure mode here: your adversary DDOSes your server, thus blocking legitimate uses of your data.) Complex rule sets would have to be created and maintained to allow "good" uses of information and prohibit "bad" uses. Most individuals could not handle this themselves, so they would have to settle for third party hosting and maintenance. A whole complicated new industry of data brokers, investigators, and lawyers would be formed. (Of course, their contracts with individuals would include exceptions for themselves.) This industry would be expensive and annoying for average people to deal with, and there would be so many forced exceptions (see above discussion of power relationships) that it still wouldn't help much. All in all, the average consumer would not benefit significantly, if at all, from DRM.
Also, the fact that cryptography and DRM have been falsely conflated is of particular annoyance to those of us who care about the issue. Cryptography is the technology with good and bad uses. DRM is one of those uses, and because it overwhelmingly favors governments and large corporations over individuals, it is a bad use.
One of the most terrible outcomes of this recent issue is the conflation of the terms QoS and Net Neutrality. By disambiguating these terms, the issue becomes much clearer.
QoS was designed into the protocol stack to allow a network provider to provide priority routing for realtime types of service over non-realtime types of service in the presence of contention for limited bandwidth. The idea is that basic services such as HTTP, FTP, and other non-realtime types of service are useful even when the link is temporarily slow, so they use a low priority. Types of services like VoIP or streaming video become completely useless below a certain bandwidth threshold, so they use a higher priority. Overall, the priority is set based on whether the given type of service is useful in the presence of low bandwidth.
It is also worth pointing out that tradionally, QoS only comes into play when there was more traffic passing through a router than the router could handle in a given instant.
The QoS protocols were never intended to discriminate based on network endpoints. If EntityX and EntityY provided the same type of service, QoS was not intended to be used to give EntityX an artificial boost over EntityY.
So keep in mind when thinking about Net Neutrality that you are discussing a whole level of issues over top of traditional QoS. In its basic form, shaping traffic based on protocol types, QoS causes no harm. Only when traffic shaping is done based on endpoints does the topic stop being QoS and start being Net Neutrality. Most likely, the traffic shaping you are referring to in your post prioritizes based on protocol types and applies those prioritization rules regardless of endpoint; therefore you are talking about QoS, not Net Neutrality.
A completely separate issue you bring up that bears consideration is the idea of what constitutes an ISP. Many organizations allow their employees to use the Internet, nominally pursuant to organizational goals. I doubt any one would object to such organizations applying whatever limits on use they want. On the other hand, commercial ISPs exist to sell Internet access to people, and should not apply traffic shaping policies, especially when only a small number of ISPs are available in a given market.
University Internet connections pose the most complex problem, but ultimately they too break down to simple categories. Within the context of administrative offices, labs, and classrooms, the university is clearly like any other organization and within its rights to limit Internet connections. However, many universities also share one Internet connection between offices/labs/classrooms and residence halls. Often, the students living in residence halls are required to pay some fee for the Internet connection (often rolled up into the costs of the dorm) and are prohibited from using an external ISP. In this context, universities clearly act as ISPs and should have the same obligations as ISPs. I am hoping that one of the outcomes of this issue is that universities are forced to differentiate their policies between office/lab/classroom and residence Internet connection, or give resident students a choice in ISP.
All one time pads are recorded from random data. You record a long stream of truly random input, then make two copies of the recording. Tne sender gets one copy, the receiver gets the other. Starting at the beginning of the pad, the sender uses each bit of the pad exactly once, then discards it. When the sender runs out of bits, he can not send any more data. The receiver decrypts decrypts likewise, discarding each pad bit after it has been used once. As long as the sender and receiver start with the same pads and don't skip or reuse any bits, they stay in syncronization.
Many perfectly good one time pads are drawn off of data "that anyone can record." For example, many pads are created from atmospheric noise. Anyone can record the same data, but unless you know exactly where and when the recording was done, it is computationally infeasible to record all possibilities, let alone brute force them.
There are many, many quasars that we record in the sky. All of them give off constant streams of random data. So it would be computationally intractable to record all possibilities or brute force a particulr message, because the attacker would have to know exactly which quasar was recorded, and exactly which instant the recording began. He would also have to know exactly which bit of the pad the sender was on when the sender started sending the message that he intercepted. All theoretically possible, but computationally intractable.
Heh. You are trying to be clever by attempting to separate hardware and software vendors using various scenarios. Far from being ambiguous, both of your scenarios demonstrate the clear superiority of this draft of the GPLv3. Here is why:
So what happens if Red Hat distributes signed binaries, and this "Tea-vo" device only runs binaries signed by Red Hat (but it requires the user download them from Red Hat manually)? Obviously, if this would require Red Hat to make available private keys, things look bad.
First, let's assume Red Hat begins shipping software under this draft of GPLv3. Red Hat does not and has never distributed signed executable binaries. Instead, they sign packages which are not directly executable. Once the packages are installed, the binaries contained in them do not have any cryptographic signature from Red Hat.
So I assume what you mean is that this hypothetical device only installs Red Hat signed packages. In that case, it must have at least a kernel and some package management software already installed. As you are installing Red Hat packages, this will likely be some variant of Linux and some variant of RPM (as well as some other supporting software). Presumably, these software have been modified from their original form specially for your device, because they do not currently enforce any such "signed code only" policy.
If the {kernel, package manager} stack is GPLv2 you, the device maker, would be required to make your changes to the above mentioned code available. If you did not use any kind of hardware DRM, then any user will be able to undo your "signed code only" policy, install the fixed software, and install any package they want. On the other hand, if you were feeling clever, you would use hardware DRM that would only run a {kernel, package manager} stack that you personally had signed with your private key. Under the spirit of GPLv2 would should have to release this key as well, or allow users to work around it, however the letter of the GPLv2 may allow you to provide neither the key nor the workaround. Regardless, Red Hat would not be obligated to release their private key, because it was your {kernel, package manager} software that is refusing to run in unsigned form, not theirs.
If the {kernel, package manager} stack is licensed under this draft of GPLv3, then everything would be the same as above. However, you would be required explicitly to provide your private key for the {kernel, package manager} signatures, or you would be required to provide a workaround. Once again, Red Hat would not be obligated to release their private key, because it was your {kernel, package manager} software that is refusing to run in unsigned form, not theirs.
So what happens if "Tea-vo Code Inc" distributes signed binaries, and this "Tea-vo" device distributed by "Tea-vo Inc" only runs binaries signed by "Tea-vo Code Inc" (but it requires the user download them from "Tea-vo Code Inc" manually)?
In any case, "Tea-vo Inc" by redistributing the software is sublicensing it to users; therefore "Tea-vo Inc" must agree to the terms issued by "Tea-vo Code Inc".
If "Tea-vo Code Inc" releases software under the GPLv2, they could get away with only running signed binaries and not allowing users to install modified software.
If "Tea-vo Code Inc" releases software under this draft of the GPLv3 and if "Tea-vo Code Inc" signed their own binaries and "Tea-vo Code Inc" code only ran in signed form, then "Tea-vo Code Inc" would be required to provide their private key to whomever they, themselves, distribute the code to; in this case, this is only to "Tea-vo Inc". When "Tea-vo Inc" then sublicensed the software to end users, they would have the ability and obligation to release that key to end users.
However, let's assume "Tea-vo Code Inc" binaries did not normally require "Tea-vo Code Inc" signatures to run, and that only "Tea-vo Inc" hardware requires such signat
The US military creates a new hardware device and to secure it, they install a non-modifiable key into it, so it only runs software that the military has signed. Now technically, they are violating the DRM clause and therefore it's illegal for them to use open source software.
The US military would not distribute such a device for use outside of the US military. Since distribution would not occur, no version of the GPL would be triggered. For purposes of the GPL, distribution only happens between two separate organizations, not between each employee within an organization. Also, Stallman has repeatedly said that the GPL derives its power solely from copyright law, which can be trumped by national security law. What I suspect you mean is that a contractor for the US military creates such a device, and distributes it to the US military. In that case, regardless of what license the original code was released under, the US military would demand full source code and full ability to make modifications. They do not accept black boxes.
In the wake of the electronic voting desaster, someone creates these plans for new electronic voting machines. However, to make it secure, he installs a non-modifiable key into it, so you can't temper with the software.
Once again, the Federal Election Commission would demand full control over the machines, including keys, as part of the contract. However, employees within the FEC would not necessarily have to be given the keys.
What it all comes down to is this: a significant difference exists between the suite of tools and functions traditionally associated with "security" and the new suite of tools and functions that are becoming known by the term "Digital Restrictions Management". The two share some common core principles, but are totally different thereafter. Certain individuals are conflating the two, either deliberately or accidentally, and are causing tremendous confusion and harm to the community.
Security are tools or functions which allow the owner (or other legitimate user) of a machine to control access to that machine. DRM are tools or functions whose fundamental purpose is to limit what the owner (or other legitmate user) of a machine can do with that machine. This purpose is diametrically opposed to Free Software and Open Source Software, which aim to give the owner complete control over his machine. The two do share some common cryptographic algorithms and it is true that for both, a hardware-kernal integration would improve effectiveness. The difference is that for security, there is no legitimate reason to prevent the owner of the computer from installing and running his own kernel on the machine. For DRM to be effective, there must be such a restriction. That is precisely why this draft of the GPLv3 requires such private keys to be made available if and only if they are required to run the program, and the owner of the machine has no way to generate his own.
Slashdot Mirror
Apt does feature an unattended-upgrades mode. It's not the default, which is annoying, but it's pretty easy to configure. It's one of the first things I configure on a new Debian box.
As for outdated packages: Debian unstable and experimental usually contain cutting and bleeding-edge versions of most open source software that is packaged in Debian. Unlike the grandparent poster, I would not recommend running sid (AKA unstable) as my main repository, because doing an apt-get upgrade has occasionally wrecked my system on sid. I use Linux Mint Debian Edition, which is based on regular tested snapshots of testing, but I do occasionally need cutting-edge packages. I would recommend looking into apt preferences, which provides a nice way to grab specific cutting-edge packages from unstable and experimental while dragging in a minimal number of unstable dependencies. So far I have had almost no problems doing this, and certainly far fewer problems than using 3rd party repositories.
I'm quite happy with Linux Mint Debian Edition. It provides a nice middle ground between stable-but-out-of-date-and-highly-political Debian and unstable-but-nice-features Ubuntu. LMDE is basically a tested snapshot of Debian testing (like CUT was supposed to be, but actually regularly maintained) with a lot of the ease-of-use features (proprietary drivers, etc) of Ubuntu. Unlike Ubuntu or regular Linux Mint (which is based on Ubuntu), LMDE is completely compatible with Debian. I can use the apt preferences mechanism to pull in some more recent packages from Debian unstable and experimental, more or less seamlessly.
Both the MATE and Cinnamon editions of LMDE are good, depending on your GUI preferences. MATE seems a bit more mature, but it's definitely old technology. Cinnamon provides modern compositing coolness, and has been making some huge improvements, but it's still rough around the edges with respect to some of the GUI configuration screens.
They just cut the new ISOs a few days ago, so the packages on them are fresh.
I agree with the parent that quality control is a problem with all new CFLs, and disagree that it is merely a matter of household electrical quality. I made the switch to CFLs throughout most of my apartment way back in 2002. I did it because my overhead lighting sockets were inconvenient to replace, and I was replacing incandescents on average one every 2 months. I bought some Phillips (or Sylvania? I don't remember) 32-watt bulbs that emitted the lighting equivalent of 120-watt incandescents. They were expensive at the time, but they worked beautifully: bright light, perfect color, and no flicker. All 9 of them kept working for well over the rated lifetime; 2 of them still are. I was very impressed and encouraged friends and family to switch.
Fast forward to last year. The bulbs eventually began to show signs of dying: flickering when turned on, and black charring around the bases of the bulbs. Over a period of months, they died and I bought some new replacement 23-watt 100-watt equivalent CFLs, from Phillips and Sylvania. Of the 7 replacements I purchased in the last year, so far 3 of them have failed, and another is showing signs of failing. Furthermore, every now and again I can detect a bit of flicker from the new bulbs, but still none from the old ones. For each failure, I have complained and gotten a coupon for a new bulb, but it's annoying and inconvenient, and it's put me in the same place as with incandescents regarding frequent replacement.
I don't believe that I have electrical problems in my apartment. These new bulbs are plugged into the same sockets that the old ones used, and 2 of the old ones still use. Furthermore, I have SmartUPSs attached to my computers and monitor their logs, and they *very* rarely record a power-related event. The power grid where I live is stable.
My conclusion is that, like most things in the business world, in the early years of CFLs, corporations put out the best product possible to gain market acceptance. Now that the market has shifted and CFLs have gained acceptance, I think that corporations are cutting corners and cutting costs to maximize short-term profits, and if this means a higher failure rates, then that's just another cost to be balanced on their books.
I hate to reply to my own posts, but I just thought of an additional comment to add.
In the example of the picture frame, likely all of the extra Wi-Fi Direct magic will be baked into the firmware.
On the other hand, for devices like laptops, I doubt that they would put this amount of software into firmware. It is likely that the extra components that turn plain Wi-Fi into Wi-Fi Direct will be entirely software that is delivered by a package of drivers and helper programs that are all provided by the OS or via a setup disc. This sort of of all-in-one setup will likely be offered to Windows and Mac users. However, users of independent operating systems, like Linux, will likely not see this, and will likely still have to manually setup these subsystems. Therefore, for Linux users, I imagine that we will see no real difference at all between a plain Wi-Fi chipset and a Wi-Fi Direct chipset.
According to Wikipedia, Wi-Fi Direct is ad-hoc mode Wi-Fi device with a built-in Wi-Fi Protected Access setup daemon, optional access point software (e.g., routing to other networks) and an as-yet undefined service discovery mechanism (e.g., UPnP, Bonjour). Basically, they are writing a standard which ties together several existing standards and best practices. This sort of meta-standard is quite common.
One example they give is a picture frame, which offers only the required ad-hoc mode Wi-Fi and Wi-Fi Protected Access daemon, and a simple service for file upload. The user would connect to it, upload pictures, and then disconnect. Nothing else would be offered by the frame, but the user would not need to do any manual setup or buy any additional devices.
A more complicated example is a cell phone which offers tethering. In addition to the required ad-hoc mode Wi-Fi and Wi-Fi Protected Access daemon, has full blown bridging/routing and service discovery daemons built-in. The user would expect to treat this device more like an infrastructure mode network in a single package; perhaps some setup would be required on the Wi-Fi Direct device, but virtually no additional setup would be required on each connected device.
So basically they are just making a standard, the implementation of which requires doing all of the things we have done manually for our own networks. This is just one step further in simplifying network setup, but not any kind of new revolution.
0) By "greatly improves the performance" do you mean by some order of magnitude, or merely by a constant factor? For example, are you going from O(n^2) to O(n log n), or is it only O(10n) to O(5n). Don't get me wrong, the latter can be useful, but the former would draw more attention from the research community. I assume you know Big-O notation and formal analysis of algorithms, otherwise you will need to learn about it before submitting a research paper in algorithms.
1) If you have never even read a full research paper, then how do you know your approach is new or better than existing approaches? First, I would recommend getting a data structures and algorithms book and a computational geometry book. Read through those looking not only for things similar to your technique, but also just to make sure you have the vocabulary correct. Then move on to Google Scholar and start looking into the more recent scholarly journals and conference proceedings on the topic. You will need subscriptions (probably via a university) to see a lot of that content, but you can try the "All X versions" link beneath most articles to see if the author published a PDF on a public web site. Books are usually years behind the state of the art, and a lot of newer research and algorithms only fully appears in papers. Also, a lot of research (most?) is not published on blogs, so your algorithm may not be as new or groundbreaking as you think. Or if it is, you still may find more inspiration to improve it from related techniques.
2) Ditto what others have said about learning LaTeX for page layout. However, if you might want to publish in a specific journal or conference, then you might have to use their specific format, so you might just want to type your first draft as plain text and a collection of images, for import into a specific LaTeX template later.
3) Writing style: You must be *very* *formal* in your writing style to be considered credible in academic circles. Have an English teacher (or similarly-minded person) go over the paper with a fine-toothed comb looking for any spelling, grammar, or word-use errors. Absolutely no slang or colloquialisms whatsoever are acceptable in a research paper. Do not use contractions. Try not to use any analogies unless they are truly apt and likely to be universally understood. Try not to use first or second person in the paper. Remember, people from all over the world from different cultures, many of whom do not speak English as their primary language, will hopefully be reading your paper, and you don't want them to get confused by any culture-specific concepts or words.
4) If your algorithm really is new or groundbreaking, then I would strongly recommend trying to publish in a proper academic workshop or conference first (try ACM or IEEE conferences on computational geometry, location-driven computing, etc.), rather than a free online archive. You will get far more credibility and exposure in academia, and you just might get your employer to pay for a junket to a conference! Workshops are more for newer, less developed research, so you may have an easier time publishing there. Conferences are for more established research, so it's harder to get in them, but they carry much more respect. Also, most workshops and conferences have industrial tracks, if your paper focuses less on formal algorithmic analysis and more on real-world uses.
5) Be warned though, that although conferences are supposed to be submitter-blind, often it's much easier to get a publication when you have a known academic co-author on the paper. You might want to look up authors of papers related to yours, find the Ph.D.s on the paper, and approach them about a collaboration. This might take a bit more time, and you would have to share credit (just make sure you are first-author), but it may be worthwhile to get more exposure and credibility. They might also be able to help point you toward making further improvements to your algorithm.
6) Please, please, do not patent your algorithm! There is more than enough patented math already; the world does not need yet another algorithm that can't be used by anyone for 20 years.
Take it from someone who owned one: the OpenMoko was a terrible phone and a terrible handheld computer. It was nearly useless when not hooked up to a computer via SSH over USB. OpenMoko earned an A for vision in getting a fully open and documented hardware interface, although the results were dubious (crappy GPRS GSM modem in an era when 3G was just becoming popular, crappy non-accelerated drivers for the video chipset). However, OpenMoko's worst failing was the total inability of the company to push a singular stable and complete platform for development; there were about 20 different incompatible distributions in various states of disarray, and you cannot have a platform for end-user app development in that sort of environment. (Imagine how unsuccessful Apple's app store or Android's marketplace would be if developers and users had to choose between 20 different incompatible distributions, all in permanent alpha status...) I think I can live with a few proprietary blobs if it means having a useful device. All of the open technology in the world means nothing if the platform dies on the vine before ever taking off. OpenMoko's ideal of a fully open phone platform proved unsustainable, as the company canceled their "next-gen" (translation: 2.5G in an era of 3G) phone and switched to producing a ridiculous "WikiReader" device which contains no pesky radio or accelerated video modules.
After more than a year of trying to use it, I finally was overjoyed to get rid of my crappy Freerunner. On the other hand, even though my N800 does not have a cell radio, I still like to use it, and am strongly considering buying an N900. I think the OpenMoko was for people who love putting together distributions and blogging about how much freer their device is compared to everyone elses'. A platform like the N800/900 is for people who like programming mobile computers to accomplish useful tasks and then distributing those programs to non-programmers.
I don't know what the protocol is for civil litigation, so I do not know whether some officer would seize your equipment at the time of service of litigation, as happens in criminal matters.
But assuming that you are able to retain control of your machines and autonomy in their use for some time after being served, then it would actually be quite difficult to securely wipe them and reinstall them without leaving behind some evidence that could be discovered by a forensics expert. Other posts in this thread do a good job of going into detail about specific ways of telling that such a wiping happened, such as looking for evidence of massive patching, or unusually large timestamp jumps. If you are caught, which is likely, then even assuming that you are not subject to criminal penalties for evidence tampering, you can still be nailed by a default judgment against you in the civil matter (where the evidence has merely to be more likely than not, rather than beyond a reasonable doubt).
So, trying to wipe a drive is a losing strategy.
Your best bet to handle this situation requires some fore-planning and regular updating of planning. You must have a brand new hard drive available *before* you get served. Them your best bet is, assuming you retain control of your computer for some time, to *immediately* remove your hard drive and destroy it, and replace it with a brand new hard drive. Then you claim in your affidavit in response to request for discovery that your old hard drive died *before* you were served, and you destroyed the old hard drive *before* you were served. You have to have bought the new hard drive *before* you were served, because they can track when the hard drive was manufactured and possibly even sold, and if the records say it was sold *after* you were served, you get nailed for perjury. Also, the hard drive should be reasonably recent, as one would be unlikely to install a 5 year old "new" hard drive in case of a failure, rather than buying a newer hard drive at the time of failure. Note that some forensics analyses can identify a specific instance of an operating system install based solely on network port scans and other traffic analysis; even though it is currently unlikely that the opponent would have used such a scan on you before serving you, to protect yourself against potential proof that your operating system instance remained the same up until the time of discovery, you should *always* have a hardware firewall between your computer and the Internet.
Of course, the above paragraph details a theoretical method to attempt to subvert the legal system. I do not support perjury and my advice to you is to not to tamper with evidence or lie about evidence.
I don't know if that is an accurate statement.
FIC is definitely the hardware manufacturer, but OpenMoko seems to be responsible for a significant portion, if not all, of the hardware design for the OpenMoko phones. (At least, this is what I glean from mailing lists where OpenMoko employees discuss the development of hardware revisions.) This would put them squarely in the hardware company category.
Furthermore, OpenMoko has said or implied that their primary software responsibilities are to write drivers for low level hardware, and to provide basic utilities for testing the hardware. It seems that they have more or less pushed the responsibility of creating a stable application development platform, AKA distribution, to the ephemeral "community".
The abdication of the development of a singular, stable, comprehensive platform for application development was a strategic blunder of monumental proportions that will ultimately be fatal to the company. In the absence of a single platform, the Free Software community has done what it naturally does: fragments. No serious mobile application developers will target the OpenMoko, because there does not exist one stable, comprehensive API that is guaranteed to exist on all phones. (Note: I am not advocating that no one else should be allowed to provide an alternative distribution, or that the official distribution should be closed-source; I advocate that OpenMoko should have allocated the necessary resources to ensure that there would exist one stable, usable, and comprehensive platform, before the first phones ever shipped to the general public.)
In the absence of a single platform, we have many competing platforms such as Gnome Mobile, home-rolled FSO, various partially incompatible versions of Trolltech Qtopia, and a seriously hacked-up Android derivative. On top of that are many competing GUI libraries, such as GTK, QT, Enlightenment, and others. What does a developer target to target all OpenMoko phones? Already, many distributions include all libraries; this is wasteful on a device with only 256MB of built-in storage. What does a developer do to make sure his app fits in thematically with the rest of the phone? There is nothing that can be done, with so many different competing GUI libraries with incompatible widget sets and theming mechanisms. OpenMoko apps look and feel like a Chimera, the mythical Greek monster made of an assortment of animals.
OpenMoko still lacks basic features such as a usable on-screen keyboard (none of the alternatives are particularly good), a usable web browser (once again, many options, none particularly good) and a usable email client. In general, we lack most apps in finger-friendly format. Note to OpenMoko developers: I DO NOT WANT to carry around a stylus with my phone. Furthermore, there is no proper centralized repository (opkg.org is close, but not a real repository), unless you use a Debian distribution, in which case you've got a whole raft of usability problems. In many cases, you have to download important applications from some random hacker's website in Russia (GPRS). And there is no digital signatures mechanism currently being used by anyone that I am aware of, so I have no idea if any of the software I download has been trojaned.
The purported advantage of the OpenMoko design over Android was the native support for X11; I was at first convinced that this was awesome, because "existing GNU/Linux apps could be ported in no time". However, I have seen what most "ports" consist of: dumping the app onto the phone with little or no GUI changes. The OpenMoko screen is 480x640, and the overwhelming majority of X11 apps are no longer are designed to work at this scale. Often, with dumped apps, I find that critical GUI elements are off-screen, with no known way to get to them. Even when the GUI fits onto the sc
As others have mentioned, `xhost +` is unnecessary in this scenario and potentially harmful.
Also, X is a bit painful to use over slow and/or high-latency connections. For this, you may want to set up FreeNX. Once setup, it works similarly to X, only optimized for low-speed high-latency connections.
The end result is the old adage I first heard applied to the Chicago political machine of the 1960s: A government does not have to be good, and rarely is. It only has to be good enough that the populace will tolerate it.
An older version of the same adage:
Prudence, indeed, will dictate that Governments long established should not be changed for light and transient causes; and accordingly all experience hath shewn that mankind are more disposed to suffer, while evils are sufferable than to right themselves by abolishing the forms to which they are accustomed. But when a long train of abuses and usurpations, pursuing invariably the same Object evinces a design to reduce them under absolute Despotism, it is their right, it is their duty, to throw off such Government, and to provide new Guards for their future security.
The last time I installed using LVM, you still needed a separate /boot partition. Maybe that's changed, though.
I used to use LVM religiously. I still love its ability to resize partitions. However, when anything goes wrong with the filesystem, it's really, really painful to try to fix it. I finally quit using LVM because of that.
Gather old computer parts from your school or lbusiness (sic), put them together, install linux and give them to schools with limited computing resources.
Most people not involved don't know this, but trying to donate to public schools can be incredibly frustrating, at least in parts of the US and especially in urban areas. Public school bureaucracy can be stifling. I have some friends who have worked with Techserv at Drexel University in Philadelphia. I have seen poor inner-city schools with almost no computers and no budget spend months or longer going through "proper channels" just to accept a donated computer. I naively thought that they would just accept them under the table but no, they have to go through the bureaucracy. Here in Philadelphia we have plenty of schools that need computers, but last I checked, Techserv has a large storage room packed with good hardware that they have trouble giving away.
Not that it is not worth doing. Just be prepared for some hair-pulling frustration and have plenty of storage space.
According to LotR, cruelty, malice and a will to dominate all life were its primary ingredients. Yup, sounds like the perfect ingredients for a successful marriage.
There was one realtime 3D map in the lobby area of the 18th floor, right in front of Turing. It was definitely there Sunday, and I think it might have been there at least part of Saturday, too. There might have been another one on the mezzanine, but I don't specifically remember it.
Did you sue? I sure as hell would have. The only thing that is going to stop this madness is for everyone these things happen to sue. And don't just go for medical bills. File for unspecified punitive damages for the mental anguish you went through almost losing your [lw]ife.
With the event you described, any decent ambulance chaser would take the case and negotiate a settlement, and the business will likely settle for an amount just less than their projected cost to win at trial. The lawyer will take most of that, so you won't end up with much. Nevertheless, if this happens often enough, the corporation will learn a lesson.
As much as I hate the way this country has become one big lawsuit factory, nowadays (often silly) personal injury lawsuits are often the only way to effect change in corporate cheapness.
You have to go BUY one my appliances, which can be a significant outlay of money, then investigate it carefully, a significant outlay of your valuable time, before you can even be certain I did use your code.
This part is a red herring. The same is true for GPLv2. Do you think copyright violations go away magically because they are violations? No, they require the copyright holder to first notice the violation, including collecting some sort of evidence of genuine violation, then commence some sort of legal action, usually involving the sending of a cease and desist notice.
You're in the hole here, and you still have to give me 60 days to come into compliance before you can terminate the license and have any leverage at all with me.
Substantially incorrect. I quote from GPLv3-draft2 Section 8. Emphasis is mine:
It is very simply stated and unambiguous. If the copyright holder notices current, ongoing violation then obviously 60 days have not yet passed since the last violation, as the violation is happening currently. Thus, the copyright holder is within his rights to put the violator on notice. Having put the violator on notice, if the violation is not corrected promptly, the copyright holder may then terminate the license at any time. There is no requirement in the language for the copyright holder to wait some specified period of time after noticing infringement before he acts. He is free to act immediately once he notices the infringement.
I suspect you did not notice the "not" in the clause "...provided 60 days have not elapsed...". That would explain your apparent confusion.
The one really scary clause in v3 seems to be the one that everyone overlooks. The license termination clause looks rather toothless in comparison to GPL2, and, outside of the guy that runs the GPL violations web site, no one seems to be paying much attention to that.
The draft 2 clarification seems to make it better. The license says that the copyright holder has 60 days from the date of last violation to put the violator on notice. In cases of accidental violation, this means that if you fix the violation, a copyright holder can't come along 2 years later and say, "You were non-compliant 2 years ago, so your license terminated." Under the GPLv2, that situation could potentially happen (although to my knowledge, it hasn't yet).
In situations of continual and/or deliberate violation, the 60 day limit would by definition be a rolling deadline, so the copyright holder could notify the violator, then terminate the license accordingly. The provision for termination under this case certainly is not "toothless".
I don't see how this differs significantly from the GPLv2. It just provides a little shield for distributors who accidentally violated the GPL, but then fixed their violation and stayed clean afterward.
Oh, joy. Now, when trying to use multiple open source projects, we can't even assume that two GPLv3 projects have compatible licenses. "libAardvark is GPLv3 with restrictions 4, 7, and 19, and gLlamaBoy is GPLv3 with restrictions 1, 8, and 21-36. We'll have to rewrite one of them."
Remember, any GPLvX code can automatically be linked to any other GPLvX code (although not necessarily to GPLvX-1 code). The allowable optional restrictions of section 7b do not impose contradictory burdens (that is, option 2 does not contradict option 3, etc) nor do they really add significant burdens to the vanilla GPLv3 (with the exception of 7.b.4 which is the web services option and the one everyone is still up in arms about). They are just minor differences in effect and the purpose of Section 7 is to allow modules with such minor licensing differences to be linked.
In fact, not only is the purpose of this section to allow you to link code under all permutations of the GPLv3, it also allows you to link GPLv3 code to various Free Software licenses that were not previously linkable due to minor wording differences or patent retaliation clauses. In fact, the controversial 7.b.4 section was to allow linking with the Affero Free Public License. The big debate should not just be whether 7.b.4 is okay, but also whether the Affero Free Public License is really a Free license.
One of the things that was discussed regarding the GPL v3 was adding a provision that made web services considered distribution that would require eleasing [sic] the source as per the GPL...
The short story is that this definition of distribution (distribution is now called "conveying" in license language) has been rejected by the FSF and does not appear by default in this draft of GPL3.
The longer story: Some web services projects do want to include a link to allow users to download source, and they do want to limit server administrators from removing this capability. To appease this group, the FSF has added an optional license provision that forbids removal of such a feature. I repeat, this is an optional license feature that takes effect if and only if a given project explicitly activates it.
I suspect that you are right and that most web service providers will not want to use up resources with users downloading web service source. So, I suspect that the market will cause any such projects to diminish in popularity. The important thing to note is that the FSF is not forcing this notion of distribution on any project using the GPLv3.
On a related note, the GPLv3 drafts Section 7b contains a list of optional license restrictions (including the above mentioned restriction) that are permissible. All of these restrictions are things that the FSF does not believe are necessary to maintain a Free program, but that the FSF acknowledges won't seriously harm user freedom if individual projects choose to activate them. Mostly, this list is provided to improve the GPLv3's compatibility with other Free Software licenses which contain equivalent restrictions but are incompatible with GPLv2. This attempt at license compatibility with other Free Software licenses is a big improvement for the GPL.
For example using DRM to protect your personal information that is in the hands of a large corporation or government. Just think about the ability to turn on and turn off the access to your ID and personal info, based on who looks at it, not just based on who copied it out of one database and into another. Think about moving from one cell phone company to another, and when they get down to your record in the database all they see is random noise, because they no longer have the DRM to your phone number and can't call you.
It won't ever happen. Ever. All the phone companies (and every other company and government) will require you to provide your information in a non-restricted format.
An entity can only roll out data restrictions if it has a power relationship over the data's consumers. For example, an RIAA label can force you to accept a restricted song, because it is the only "legal" provider of that song. On the other hand, you the individual consumer mean nothing to a corporation, as there are millions of others like you.
In theory, companies could be forced to accept a restricted format if a large percentage of their customers cooperated in a boycott unless and until the restriction was accepted. (Good luck dealing with governments.) Experience has shown that average people don't care about privacy issues enough to go through the inconvenience of a boycott.
One thing that the current situation has taught us is that if there is a legitimate way for an entity to get non-restricted data, the non-restricted data will proliferate at the expense of the restricted data. DRM only works if there is no non-restricted equivalent. As so many corporations and governments will force you to give away your non-restricted data, that data will proliferate through the society, just as it does now.
DRM is ultimately infeasible for the average individual. Each person would need to have a server online at all times, permitting or denying access requests. High security would be needed, otherwise entities would just break in and give themselves whatever permissions they want. Uptime and connectivity would also be strict requirements, otherwise legitimate uses of data would be blocked pending approval. (Or imagine the malicious failure mode here: your adversary DDOSes your server, thus blocking legitimate uses of your data.) Complex rule sets would have to be created and maintained to allow "good" uses of information and prohibit "bad" uses. Most individuals could not handle this themselves, so they would have to settle for third party hosting and maintenance. A whole complicated new industry of data brokers, investigators, and lawyers would be formed. (Of course, their contracts with individuals would include exceptions for themselves.) This industry would be expensive and annoying for average people to deal with, and there would be so many forced exceptions (see above discussion of power relationships) that it still wouldn't help much. All in all, the average consumer would not benefit significantly, if at all, from DRM.
Also, the fact that cryptography and DRM have been falsely conflated is of particular annoyance to those of us who care about the issue. Cryptography is the technology with good and bad uses. DRM is one of those uses, and because it overwhelmingly favors governments and large corporations over individuals, it is a bad use.
One of the most terrible outcomes of this recent issue is the conflation of the terms QoS and Net Neutrality. By disambiguating these terms, the issue becomes much clearer.
QoS was designed into the protocol stack to allow a network provider to provide priority routing for realtime types of service over non-realtime types of service in the presence of contention for limited bandwidth. The idea is that basic services such as HTTP, FTP, and other non-realtime types of service are useful even when the link is temporarily slow, so they use a low priority. Types of services like VoIP or streaming video become completely useless below a certain bandwidth threshold, so they use a higher priority. Overall, the priority is set based on whether the given type of service is useful in the presence of low bandwidth.
It is also worth pointing out that tradionally, QoS only comes into play when there was more traffic passing through a router than the router could handle in a given instant.
The QoS protocols were never intended to discriminate based on network endpoints. If EntityX and EntityY provided the same type of service, QoS was not intended to be used to give EntityX an artificial boost over EntityY.
So keep in mind when thinking about Net Neutrality that you are discussing a whole level of issues over top of traditional QoS. In its basic form, shaping traffic based on protocol types, QoS causes no harm. Only when traffic shaping is done based on endpoints does the topic stop being QoS and start being Net Neutrality. Most likely, the traffic shaping you are referring to in your post prioritizes based on protocol types and applies those prioritization rules regardless of endpoint; therefore you are talking about QoS, not Net Neutrality.
A completely separate issue you bring up that bears consideration is the idea of what constitutes an ISP. Many organizations allow their employees to use the Internet, nominally pursuant to organizational goals. I doubt any one would object to such organizations applying whatever limits on use they want. On the other hand, commercial ISPs exist to sell Internet access to people, and should not apply traffic shaping policies, especially when only a small number of ISPs are available in a given market.
University Internet connections pose the most complex problem, but ultimately they too break down to simple categories. Within the context of administrative offices, labs, and classrooms, the university is clearly like any other organization and within its rights to limit Internet connections. However, many universities also share one Internet connection between offices/labs/classrooms and residence halls. Often, the students living in residence halls are required to pay some fee for the Internet connection (often rolled up into the costs of the dorm) and are prohibited from using an external ISP. In this context, universities clearly act as ISPs and should have the same obligations as ISPs. I am hoping that one of the outcomes of this issue is that universities are forced to differentiate their policies between office/lab/classroom and residence Internet connection, or give resident students a choice in ISP.
All one time pads are recorded from random data. You record a long stream of truly random input, then make two copies of the recording. Tne sender gets one copy, the receiver gets the other. Starting at the beginning of the pad, the sender uses each bit of the pad exactly once, then discards it. When the sender runs out of bits, he can not send any more data. The receiver decrypts decrypts likewise, discarding each pad bit after it has been used once. As long as the sender and receiver start with the same pads and don't skip or reuse any bits, they stay in syncronization.
Many perfectly good one time pads are drawn off of data "that anyone can record." For example, many pads are created from atmospheric noise. Anyone can record the same data, but unless you know exactly where and when the recording was done, it is computationally infeasible to record all possibilities, let alone brute force them.
There are many, many quasars that we record in the sky. All of them give off constant streams of random data. So it would be computationally intractable to record all possibilities or brute force a particulr message, because the attacker would have to know exactly which quasar was recorded, and exactly which instant the recording began. He would also have to know exactly which bit of the pad the sender was on when the sender started sending the message that he intercepted. All theoretically possible, but computationally intractable.
First, let's assume Red Hat begins shipping software under this draft of GPLv3. Red Hat does not and has never distributed signed executable binaries. Instead, they sign packages which are not directly executable. Once the packages are installed, the binaries contained in them do not have any cryptographic signature from Red Hat.
So I assume what you mean is that this hypothetical device only installs Red Hat signed packages. In that case, it must have at least a kernel and some package management software already installed. As you are installing Red Hat packages, this will likely be some variant of Linux and some variant of RPM (as well as some other supporting software). Presumably, these software have been modified from their original form specially for your device, because they do not currently enforce any such "signed code only" policy.
If the {kernel, package manager} stack is GPLv2 you, the device maker, would be required to make your changes to the above mentioned code available. If you did not use any kind of hardware DRM, then any user will be able to undo your "signed code only" policy, install the fixed software, and install any package they want. On the other hand, if you were feeling clever, you would use hardware DRM that would only run a {kernel, package manager} stack that you personally had signed with your private key. Under the spirit of GPLv2 would should have to release this key as well, or allow users to work around it, however the letter of the GPLv2 may allow you to provide neither the key nor the workaround. Regardless, Red Hat would not be obligated to release their private key, because it was your {kernel, package manager} software that is refusing to run in unsigned form, not theirs.
If the {kernel, package manager} stack is licensed under this draft of GPLv3, then everything would be the same as above. However, you would be required explicitly to provide your private key for the {kernel, package manager} signatures, or you would be required to provide a workaround. Once again, Red Hat would not be obligated to release their private key, because it was your {kernel, package manager} software that is refusing to run in unsigned form, not theirs.
In any case, "Tea-vo Inc" by redistributing the software is sublicensing it to users; therefore "Tea-vo Inc" must agree to the terms issued by "Tea-vo Code Inc".
If "Tea-vo Code Inc" releases software under the GPLv2, they could get away with only running signed binaries and not allowing users to install modified software.
If "Tea-vo Code Inc" releases software under this draft of the GPLv3 and if "Tea-vo Code Inc" signed their own binaries and "Tea-vo Code Inc" code only ran in signed form, then "Tea-vo Code Inc" would be required to provide their private key to whomever they, themselves, distribute the code to; in this case, this is only to "Tea-vo Inc". When "Tea-vo Inc" then sublicensed the software to end users, they would have the ability and obligation to release that key to end users.
However, let's assume "Tea-vo Code Inc" binaries did not normally require "Tea-vo Code Inc" signatures to run, and that only "Tea-vo Inc" hardware requires such signat
What it all comes down to is this: a significant difference exists between the suite of tools and functions traditionally associated with "security" and the new suite of tools and functions that are becoming known by the term "Digital Restrictions Management". The two share some common core principles, but are totally different thereafter. Certain individuals are conflating the two, either deliberately or accidentally, and are causing tremendous confusion and harm to the community.
Security are tools or functions which allow the owner (or other legitimate user) of a machine to control access to that machine. DRM are tools or functions whose fundamental purpose is to limit what the owner (or other legitmate user) of a machine can do with that machine. This purpose is diametrically opposed to Free Software and Open Source Software, which aim to give the owner complete control over his machine. The two do share some common cryptographic algorithms and it is true that for both, a hardware-kernal integration would improve effectiveness. The difference is that for security, there is no legitimate reason to prevent the owner of the computer from installing and running his own kernel on the machine. For DRM to be effective, there must be such a restriction. That is precisely why this draft of the GPLv3 requires such private keys to be made available if and only if they are required to run the program, and the owner of the machine has no way to generate his own.