While I appreciate your general point, injecting a bit of reality back into the discussion by mentioning the actual effect on performers in the business, I disagree with one specific point:
[T]omorrow I'll be spending the hour or so before each shoot doing unpaid paperwork for the government...
Incorrect, unless you are donating your entire performance or have otherwise specifically negotiated a "discount" fee.
Rather, that hour of paperwork is factored into the cost of doing business, thus raising the performing rate somewhat for the hours you are paid for. As such, it's indirectly paid, in the same way the mail and web accounts bundled with a normal consumer ISP account are indirectly paid, altho some may call them "free". In the same way that the ISP isn't there as a charity, and must recover costs, thus raising monthly fees to cover the cost of providing all the "bundled" services, so unless you are operating as a charity with your performances, as a cost of doing business, your performance fees also figure in the time necessary for filling out that paperwork.
As another, actually more direct comparison, consider the "unpaid" time many workers spend commuting. Under normal circumstances it's self-evident that they are doing it for the money, and as such, that "unpaid" time is really "indirectly paid" time, as they have obviously figured it into the cost of doing business or they'd not be employed at that location at that wage, but rather either somewhere closer or at a higher wage, in ordered to cover the cost.
So as I said, unless you are doing it as a charity (which the whole gripe about being unpaid for the paperwork time would imply is not the case), it's really indirectly paid time, because it's figured into the compensation as a part of doing business. Were it not so, you'd either be demanding higher pay, or working elsewhere, as otherwise, taken a whole, the pay would not be "worth it" to you, and you'd be doing something else with that time instead.
I do agree with the point, however, and am glad you took the time to post it. It'd be nice not to have this cost of doing business, or to reduce that "hour" to "10 minutes". Unfortunately, that's not likely to happen immediately, or from this single case alone, altho it is likely to help keep that "hour" from becoming "two hours".
That's one comparison and it's reasonably valid, but it's not the one I had in mind. Rather, I was thinking desktop/workstation, but sorted more by age. Linux is known for its ability to give old hardware new life. While I removed any trace of proprietary OS from my systems some years ago, I've recently had a bit of experience again with them as I've a bit of a reputation as a computer guru and some folks have needed password resets and the like done.
One I had to work with was an old half GHz machine with 64 MB of memory, running (what I refer to as) "eXPrivacy". It basically wouldn't run the recovery LiveCDs (STD and INSERT) I had downloaded because it simply didn't have enough RAM. Well, it booted to CLI mode and I could do a bit from there, but it wouldn't load X, as it said X required at least 64 MB memory and as this was a liveCD, it was running out of RAMDisk and using part of that 64 MB for that. FWIW, the desktop environments they tried to run were IceWM and something similarly light, I forgot what. Sad to say I didn't have a lot of luck with this computer (which I was trying to virus scan), because I simply wasn't familiar enough with the territory to know how to accomplish what needed done without enough memory to load X and get at the normal documentation and set up the network, etc. As it wasn't my machine I didn't really know the territory well enough to safely do a lot on my own, I didn't try shrinking the main partition to give me enough swap to work with to do what I needed to do. The owner took it back and I believe had another "friend" reinstall whatever pirate stuff they had to work with.
That's why I gave a higher figure for LiveCD use. The half GHz, 64 MB machine would have worked well enough with IceWM installed locally, so it wasn't trying to run off RAMDisk and had some swap space available, but I was trying to run off LiveCD/RAMDisk, and it just wasn't working. 92 or 128 MB would have worked much better.
The second machine I had to work with (password reset this time not malware, legit as I knew the guy and it was his data) was again eXPrivacy, but a bit higher speced, 1.2 GHz or so, 384 MB RAM. Both recovery LiveCDs worked MUCH better on it, and even off LiveCD, it ran rather noticeably faster than the eXPrivacy Pro it had loaded. It could have handled a heavyweight desktop if necessary, but I'm sure it was much more responsive with IceWM and etc.
Thus the minimum decently workable memory for a reasonably light (reasonably modern, not Win9x era) desktop LiveCD is going to be 92-128 MB, 64-92 MB running native installed to disk with swap. It'll be rather higher with either of the full heavyweight desktops -- 256-384 MB is probably about the low end I'd consider reasonable to work with, altho a lot can be done with swap and 128 MB might be barely usable, if it's absolutely necessary.
The point there is that for a lot of folks running second hand hardware, this level of resources is what they are working with.
No one says "Gnome doesn't have x functionality" or "KDE does have very good y functionality". It all boils down to how many settings are exposed. Surely in that case then this is a presentation layer issue not a fundamental architecture issue. Wouldn't it have been better to have developed one desktop environment engine and two presentation layers[? They] are basically the same under the hood.
Basically the same under the hood? Let's just say I disagree. GNOME's C based, KDE's C++ based. KDE's much more integrated, designed and implemented with much higher reuse of components (at a cost of very high and cross-interlinked dependency requirements, much higher and with more interlinked complexity than GNOME, even to run a single app or two in another desktop environment -- compile these things and all updates from source as I do on Gentoo and you KNOW these things =8^/ ) There are other differences as well with the current generation, dbus vs. dcop, et
Then I look at the people slagging [Novell] - they all have agendas. FSF wrt the GPLv3
Actually, I was rather surprised at how easily the FSF let off Novell on that one, although it was arguably because they believe they entrapped MS in doing so. (It'll take a case to prove that one way or the other, but it's an interesting legal maneuver regardless.) Still, RMS was sounding very fair even before anything about forcing MS' hand ever came up, suggesting that it might be best to grandfather in existing agreements -- which pretty much meant Novell only at that point.
So I don't believe you can fairly lay that at the FSF' feet. The FSF position in fact looks rather uncharacteristically compromising, to me, compared to the many of the Novell slaggers.
Me? I'm a Gentoo guy now, and before that, hadn't tried SuSE because I didn't like their "non-free" no commercial use license on Yast and the like (an approach it should be pointed out Novell quickly changed to full GPL, BTW; they get major points here for that, but I was already switched from Mandrake to Gentoo by then, and Gentoo's far more my style). So it's nothing I'm directly involved in, but I certainly thank them for their contributions, the same as I wish they hadn't done the MS thing, but understand why they did it. So basically as a GPLv3 supporter, I'm taking my queues from the FSF on this, and the FSF gave them a pass, so I'm willing to do so to.
As for Sun, they've been quite involved in the formation of the GPLv3, and I'd not be surprised to see them ultimately dual license OpenSolaris CDDL/GPLv3. If they do, things could get rather interesting... as it could quickly be adopted by the FSF in place of the long floundering GNU/HERD and take the place of both it and Linux as the darling of the FSF. If the RMS predictions on Tivoization, patents, and digital restrictions management even come close to true as well... and Linux hasn't at least started the switch to GPLv3 before it all starts coming down, GNU/OpenSolaris could very possibly be the successor to Linux, and ultimately be the one to achieve that "world domination" that the Linux folks keep half-joking about.
Of course, that's a pretty long set of successive still long-shot ifs there, and while the FSF and friends would welcome a GPLv3ed OpenSolaris, most of the other IFs there aren't too pleasant to contemplate, so I think it's safe to say few hope it all happens that way, but it's possible.
The only thing we need now is one desktop environment rather than two. Sigh. I've given up even caring which on wins anymore I just wish we had one decent one.
Not me! The problem is that in this case a single size does NOT fit all! There's a need for at least three and likely five "environments" on the desktop. Here's how I figure.
The first two are the "big two". Fairly heavyweight, the problem here is that the approaches differ and "never the twain shall meet." Then there's XFCE, lighter weight while still being rather featureful, and for the really "resource challenged" (read as <384MB memory "LiveCD", <256MB memory running of of writable media, these days, or 92MB/64MB if you wish to be really conservative), something line IceWM. Finally, some find ION type WMs more to their liking. For them, the standard WM/environments simply aren't organized or efficient enough, and can never work.
Focusing again on the "big two", the problem is as follows. The GNOME approach (characterized from the opposing viewpoint, and obviously drastically simplifying) seems to be that in most cases there is "one single best UI choice", and that if there's a split as to which way is best, it's simply because the "correct" UI presentation hasn't yet been found. Their approach to customization is minimalistic, the less setting there are to confuse the user, the better. The common complaint from the "control freak" (me) and/or "power user" and/or "developer" (Linus) is that tools and choices that should be there, tweaks that should be possible, simply aren't... at least from the GUI... and this they/we find EXTREMELY frustrating!
The perfect example is the UI elements color chooser applet. Even MS has one, yet GNOME for years somehow didn't find it necessary. I'm not talking about just a color chooser applet, sure they had that, but one couldn't use it to do something as simple as choosing the background and text color of a command button, without choosing an entire theme and changing all sorts of unrelated stuff at the same time! I'm not sure if they ever got one or not (at least in GNOME-core, I must assume someone has implemented an option applet to do it), but from my viewpoint, that's so basic a required functionality that I can't consider a desktop environment even half developed without it! Of course, in KDE, it's the colors control panel applet, control panel, right where one would expect it, shipped in kdebase, again, right where one would expect it. It has existed since at least KDE 2.x.
Contrast the "if you don't find our imposed choice best you obviously don't know what's good for you" approach of GNOME with the KDE approach, which could be characterized (hopefully even handedly simplifying/exaggerating) as "if there's a choice in UI behavior, program all possible choices and expose them as an option for the user to choose." The common complaint from the "I just want it to work" crowd is that all those options are confusing and just get in the way of actually getting things done. They find this confusing and frustrating too, I suppose in equal measure to the power users and etc trying to work with GNOME.
The problem is that in terms of basic UI approaches, as I said, "never the twain shall meet." Sure, there can be some working together to make an app from one desktop work well on and function somewhat like the other if it finds itself in that environment, and there are projects to that end. However, I've come to realize that the two approaches are both necessary and fill a need, and that if either desktop project were to suddenly collapse, the developers on the other would likely be first in line donating to get a new one started! Why? Simply this. As long as the folks taking the other approach have their own sandbox to play in, they won't be trying to change the rules in and screw up ours! I'd hate to have GNOME users and devs trying to "simplify" KDE to their liking, removing all the tweaking ability many KD
There are standard SIP clients for all the major OSs. It's a standard, after all. There are also standard SIP hardware devices, from ATAs (analog telephone adaptors) in both end device and router versions, to Ethernet based SIPPhones (including PoE, power over Ethernet, so single cord) to cordless wifi devices, to computer card phone adaptors, available from several different manufacturers and multiple vendors. There are also both open (Asterisk) and proprietary (Cisco, among others) VoIP/PBX implementations as complicated and featureful as you care to get.
I recently switched to 100% VoIP here (I can't justify the additional cost for cell service, so this was from standard telco land-line). One of my big requirements was everything I got was SIP-standard, no-lockin. The going (US) rate is ~$25-30/mo including all taxes/fees, or prepay a year for $199 plus fees (which is what I did), which works out to $16.58/mo, and my fees are $2.50/mo, so I'm paying <$20/mo total, by prepaying. That includes at least US/48 as if it were "local", plus incoming. The differentiation between providers is that some provide up to 25-nation "local" calling for that, while others include a few extra features -- altho all the "standard" features the telcos like to charge extra for, caller-id, voice-mail, etc, are included at no additional cost by nearly all providers. Since all the folks I call are in the US, I chose the extra features, including such things as selective announcement voice mail (so my friends get a different greeting than ordinary callers, can be handy at times) and scheduled automated wakeup/reminder (b-day, anniversary, etc) calls -- no additional cost! =8^)
If you do mostly net calling, as I think with Skype, you can get that for free. If you need incoming phone only, that's available with a local number in many cities in the US from $2/mo, if you shop around. Outgoing only, available from $10-ish/mo. unlimited or 4 cents a call (NOT per minute, per call) or a penny a minute, both without monthly fees, just usage. (The 4 cents a call thing is to the US, but provided by a company in Norway, Vyke.com... I couldn't get my US credit cards to work with it, unfortunately.) There's also 500-ish minute accounts and the like available, and 35-nation, regional, and nearly worldwide "local" calling plans, for those that need them. "Unlimited" does in the cases I've been talking about refer to "residential" service, but there's also commercial service, without residential use restrictions, available, from $30/mo or so, and fully unlimited, wholesale resale and phone bank and etc services allowed, at per minute rates, of course depending on provider.
I went with a two-line ATA/router, which plugs in between my cable modem and my network, and can handle two separate SIP based phone accounts. The two phone lines (two separate jacks, two separately controlled SIP accounts) plug into it pretty much as they'd otherwise plug into the telco NID at the demarc point. The adapter cost $57 -- again, I elected to buy my own unlocked SIP standard based equipment, for additional flexibility and no lockin. I bought a grandstream, but there are other brands with a variety of features and at a variety of costs. Mine is about the size of a cigarette pack -- which surprised me as I was expecting something about three times that size.
** I did have to go to the net to buy it, as everything the local brick and mortar stores seemed to offer was locked to one provider or another, generally Vonage, Lingo, or Skype (the latter proprietary not standard SIP of course). However, going local rates for the locked versions was about double what I paid ($57 as mentioned) for my Grandstream on the net, so it was well worth it.
Since I no longer have a regular land-line, I bought a (separate, again standard/ordinary) UPS to power my ATA, cable modem, and cordless phones, so I have phone service even when the power goes out, as long as the cable internet stays up (and it should be fairly reliable as they run their own phone service in competition with the telco, too, and have battery backups for it).
If you released code under a dual license such that the part that was GPL before is now dual licensed, you have violated the license on the GPL code (assuming you linked to it and etc. and etc, thus the "mere aggregation" clause didn't apply), unless of course you got the permission of the author to do so.
Now what you/can/ legally do as long as the licenses are compatible is release the combined work under your own choice of license (including dual, but you aren't obligated to), acknowledging the license on the component, with clear delineation of said component and with its license reproduced therein, so there's no mistaking what part of it is subject to which license.
You may also release your own code under a non-compatible license, but that restricts distribution of the GPL component, so a user would have to procure that separately and combine them himself. That's questionable, but has been to this point tolerated, as with the NVidia and ATI kernel modules, for instance. (With at least NVidia, they have a buffer layer as well. The buffer layer is MIT/BSD licensed and as such is compatible with both the proprietary license of the core binary-only module and the GPL of the kernel, and only the buffer code links to both. Thus their proprietary code doesn't directly link at all to the GPL code, adding another layer of safety, particularly since it's said to be the same as the core of the MS Windows driver and thereby cannot be be easily argued to be derived from the GPLed Linux code.)
Back to the main case under discussion, answer me this. What's the significance of the dual license, then, if they can't be "alternatively" split? It simply doesn't work, because by one interpretation, both would apply and the two aren't that compatible, so ti doesn't work, by another, the stricter would apply, so source would have to be provided, and that would offend the BSD folks and definitely anyone that tried to use the source in closed code, and by a third, equally as valid as the others, the liberal case would apply, in which case it might as well be BSD only. They are all three equally valid, so none can be said to apply.
Looking at it the third way, as it seems the BSD folks wish to do, if it were made a component of GPL code and improvements were made, then proprietary coders could take that source and do with it as they wished because the BSDL was still attached, which would violate the GPL. Thus, where's the use in dual-licensing it in the first place, since the GPL can't be held to apply with or without the dual license?
That doesn't work for the same reason the reverse doesn't work. GPL folks can't demand code improvements from proprietaryware fols that might have used the dual licensed code. That's the second case. The first case is that both apply, which isn't logically consistent either since the source can't at the same time be shielded as the BSD allows and provided as the GPL obligates, so all three possibilities of the AND case simply fall apart.
Thus, the only possible logical interpretation is that the OR case applies. If the OR case applies, there's no problem, because OR was chosen. It's not rewriting the license of someone else's code, because they wrote it that way in the first place, specifically allowing the split to be made, both because they used the term "alternative" and because there's no other possible logical construction.
Seems as if just as some in SCO didn't understand what they bought, so some here may not have understood what the license gave away.
That's my thought as well. If it's BSD AND GPL, it either can't be distributed at all, because the two have terms that can't BOTH be satisfied, or it reduces to one or the other, BSD if read liberally, GPL if read conservatively. If it reduces to GPL, the BSD folks are going to be rather unhappy. If it reduces to BSD, there's no point in the dual license in the first place.
Therefore, the only LOGICAL conclusion is OR (regardless of the fact that OR is what alternatives means). The BSD folks wouldn't be (and demonstrably aren't) comfortable with folks demanding source, so they are obviously OK with dropping the GPL side. What's wrong with the GPL guys therefore dropping the BSD side? (Note that interpreting it as explicitly requiring continuing the BSD license would return to the AND case above, which in the case of the specific dual license logically falls apart.)
Yes, you can. That's what dual licenses/do/, allow you to use either one.
After all, what would be the point of the dual license if neither one could be dropped? Wouldn't that be effectively exactly the same as the BSD license? Or taken the other way, wouldn't that mean that anyone could demand code under the terms of the GPL?
It can be pointed out that the BSDL already gives GPL folks the right to use the code under the terms of the BSDL (that is, keeping the attributions and BSDL in tact on that specific code, but in a work licensed overall under the GPL). Thus, the dual license don't change anything there, if both licenses must be maintained intact.
Conversely, if both license must be maintained intact, then anyone can demand the sources or that redistribution be stopped, under the GPL side, which isn't going to fit the intent of the BSDL very well.
Alternatives mean just that. See the Trolltech/Qt and MySQL cases, among other examples. Neither of those requires that the GPL continue to be propagated on the proprietaryware side, nor that the proprietary licenses continue to be propagated on the GPL side. Some on the GPL side continue to propagate the other license downstream as well, so that the end user may choose, but not because they have to.
You say it makes the code less free. I say it makes the code more free, because it guarantees it will remain free.
Perhaps we can agree on a statement that it would/change/ the freedoms applying to the code. I don't see how there can be argument on that, because regardless of whether one believes it's more free or less free, it certainly changes the applied freedoms.
Except for one thing: As the author of the new code, you/cannot/ be forced to relicense your own (new) code. You CAN be forced to choose between doing that and ceasing redistribution of the GPL code (and therefore the combined work); you/may/ be forced to pay damages for distributing the GPL code outside the license, but you/cannot/ be forced to relicense your own code. (The extreme case where you forfeit your property due to failure to pay the court ordered damages due to the unlicensed distribution is separate, as that's not forcing you to relicense your code due to the violation, but simply due to failure to provide suitable other assets to pay the court imposed damages.)
That's one thing MS and the others deliberately fail to mention. Even if they took GPL code, they couldn't be directly forced to release their own code. The could choose to stop distributing until that portion was rewritten to be non-infringing, and pay appropriate penalties instead, and I'm sure that's what they'd choose to do unless it was something trivial. If it took them a few million dollars to rewrite the offending code in 30 days, skipping the usual test regime if they had to, during which they couldn't distribute and were thus losing millions per day, they'd do it. Of course, better to not be found in that position to begin with, but there's nothing saying they'd have to open the code they created around what they "borrowed", as long as they were willing stop distribution until it was rewritten and pay the damages in the mean time.
You obviously didn't RTFA. The IR beam and its reflection simply serves as a lock on the positioning of the eye in space, allowing a/relative/ comparison of the position of the pupil. Thus the reflection of the IR beam gives you nothing on its own. Even filming the motion of the eye won't give you an absolute fix on the password (tho it could significantly narrow the brute force search domain), since it's looking at a virtual keyboard to do its "typing", and you'd have to have a fix on where that is as well, in ordered to know whether the movement was a single key or a whole keyboard away.
To make things harder, one could even shift the position of the virtual keyboard every number of characters entered.
Of course, this doesn't solve the trojan keylogger issue at all (despite what TFA says), since the device driver would presumably enter characters into the same input buffer as a conventional keyboard would. It'd therefore arguably help against shoulder surfing in controlled installations such as ATMs, but couldn't do a thing to secure braindead joe user's passwords, with its hundreds of trojan/spyware/malware installations, because braindead joe simply doesn't have the motivation to care enough about such things to invest the necessary time to defend himself from them, and is in fact quite comfortable in his braindead state, blaming everyone/else/ for the problem.
The problem for the cracker, however, is that they'd have to have two vantage points at once, one watching the eyes, the other watching the virtual keyboard the eyes were focusing on, to get a position reference on it. Otherwise they'd have roughly the same problem as pupil tracking without the reflected spot, no reference fix. Was that movement a single letter, or to the other side of the keyboard, or somewhere in between? Just observing the eyes could certainly significantly cut down the brute force search space, thereby equally weakening the strength of the password, but it'd be anything but a one for one correspondence. (The reason the software doesn't have this problem is because it is aware of the relative position and size of the virtual keyboard onscreen.)
One could even deliberately reposition the virtual keyboard after every number of characters, as well, thus further throwing off third party eye monitors.
What TFA didn't mention, however, even tho it compared with keyloggers, is that presumably this would replace typed input as just another type of input device. As such, one may not even have to modify the keylogger to have access to the character input stream from the eye input device driver, just as it does from the keyboard device driver. A keylogger generally logs the character input stream, not the raw symbol stream, and the character input stream remains the same, no matter what device it's from or how exotic it may be. The only way around that would be a custom vertically integrated application that handles the entire stack monolithically, instead of as components tying into the conventional input stack. That'd be a huge implementation and portability headache, as it would have to be custom developed for each hardware and software combination implementation. Possible, yes, in embedded or limited hardware/software situation such as (say) ATMs, but not generally deployable without running into the conventional keylogger trojan challenges everyone else faces.
Well, in reply to the GP, at least the GPL makes specific exception for the OS, so no, NOT everything can be regarded as derived from the OS, because it's specifically excepted.
The same applies to the case in the parent where a company has something 20/50/30 GPL/AFL/own code. The GPL specifically excepts what one does for one's own use, and that/includes/ companies (in at least the corporate form, and AFAIK, the partnership as well, don't know about others). Thus, the only possible problem with the example above is the AFL, which I'm not familiar enough to evaluate. The GPL is fine with it and it's assumed that the company is fine with it for its own code as well. (This is why controversial semi-closed-source modules such as those from NVidia and ATI aren't issues at all for the users, only possibly for the the distributors including the creators, ATI and NVidia. As far as the GPL is concerned, a non-distributing user always has an absolute right to do whatever he wants with the code, subject of course to contrary provisions of the licenses on the other code he may be merging, but that's of no interest to the GPL, only potentially to the other license and its licensor.) In GPL terms, "distribution" within the company isn't considered distribution at all. I'm not sure how this relates to cross-subsidiary distribution, however. You'd best check that with the FSF or get the opinion of your own lawyer for that. (Borrowing from another poster's idea... "Damnit, Jim. I'm a free software user, not a lawyer.")
All that said, the last paragraph of the parent really says it all. Companies ARE used to being able to buy away, with money, any copyright issues, and this whole idea of payment in code has taken and continues to take quite some getting used to. Still, given the large and continuing to increase share of freedomware in at least the server market today, enough businesses have accepted the deal that failing to do so can put one at crippling competitive disadvantage.
While the same share hasn't reached the desktop yet, acceptance of the formerly found radical licenses of FLOSS on the server means companies have generally faced the license issue to at least some degree, and that's one less obstruction to adoption on the desktop as well. (Of course, desktop adoption has been only inching up, more outside the US than in, but with Dell's successful and expanding Linux on the desktop intro, one can hope the dam has finally broken. Regardless of whether this is the much vaunted "Year of the Linux desktop, one thing I've found for sure, riding the Free/Libre and Open Source Software wave has never been a dull ride for long, and if there's one fairly safe prediction, it's that such will continue to be the case for quite some time yet! =8^)
Well, FLOSS programmers and businesses have issues with license proliferation, too. What happens if they want to use two libraries in their product, under two incompatible licenses?
As for code under the GPL and similar freedomware licenses, as with code under other pay-to-incorporate-into-your-product licenses, it simply comes with a license allowing you to do so under pre-set terms as long as you agree with them. If you don't, there's nothing stopping you from contacting the developers and negotiating other terms satisfactory to both parties. While pay-money-to-incorporate software developers choose to ask for money in their preset agreements, return-your-code-to-incorporate software developers ask for that instead. In both cases, if you don't like the terms, contact the developers and negotiate different terms. In both cases if you can't come to an agreement, well then, you use something else or code your own. It's that simple, and there's nothing other than the form of preset agreement separating the two types of software developers or their software.
In fact, far from business incompatible, there are a number of very successful companies using the GPL as at least one of their preset licenses. Trolltech is one such company that has chosen to incorporate BOTH types of preset license, giving developers wishing to incorporate their software a LOT of flexibility. Those who are planning to make their code free already can choose the GPL version and GPL their own code. Those who prefer to lockup their code instead of sharing it for the betterment of humankind, can choose the preset pay-money license instead of paying their code back. Great! That allows Trolltech to continue development for continued incorporation by BOTH those who release their code to the common betterment of humanity and those that prefer to lockup their code, and Trolltech is a thriving business as a result of this. Again, as with any other code shipped prelicensed, if you don't like the terms of either preset license, you are free to contact them and negotiate other terms of mutual satisfaction to both parties. Again, if such negotiation fails to produce satisfactory results, you remain as free as ever to look elsewhere or develop replacement code yourself.
So there's no problem either way. You either except the preset terms, or you contact the developers to negotiate other terms or look elsewhere. As with any other deal, if one party can't abide the terms, they simply negotiate other terms or look elsewhere. No third party left out on their own, any more than any other party who can't abide the preset terms and can't negotiate other satisfactory terms.
From other articles I've read on this, it's both. Specifically, this is the national vote that determines how the US rep @ ISO votes. At the int'l level, each national vote has the same weight.
Obviously, the US isn't the only nation going thru this at this time. MS has been attempting to stack the deck (typically, a working group with half a dozen or a dozen voting members, suddenly has 50 MS partners pay the couple grand to join and vote in the 6 weeks before the national vote), but perhaps surprisingly, even with that sort of stacking, they've been losing votes. Often, they do get the majority, but because this is supposed to be a consensus standard, it requires a 2/3 vote. Several nations have already voted no at the national level, while I believe two had voted yes (in the story I read), and some of those "no"s aren't yet written in stone -- as in the US, MS is playing tricks with the process, adding votes not originally in the scheduled process, etc.
Still, due to the effect of MS' money and the pull they have on their partners to stack the deck, it's really surprising they're having the trouble they are. I'm sure it is to them too, or they'd not have been so insistent on the super-expedited schedule. They are used to getting their way, buying it, skirting the law if necessary, bribing it, whatever, and it's actually surprising them that the whole world isn't simply rolling over for them any more!
The thing is, however, their effort has at least two strikes against it, in addition to the raw politics. One, ODF has already been voted in as a standard, and many of the comments are to the effect that two standards on virtually the same thing will only confuse the situation. They say MS should work to improve and update the existing standard instead, if it's so bad. Two, the MS effort is simply very poor standards material, technically. Many behaviors are defined in terms of how (proprietary) product X did it with version Y (handle wrapping like Word95 did in case Z, etc.). Defining a behavior by reference to a second behavior that itself isn't defined, simply doesn't work well in terms of a standard that everyone is supposed to be able to implement and have all versions interoperable with the standard conformant files written by other implementations. What's interesting, and must be givng MS fits, is that even after they've stacked the deck like they are doing, they're still having a tough time of it, in part because once these partners actually study the thing, enough of them decide it's bad enough they can't vote to approve it as currently speced out regardless. If MS hadn't been so insistent on expediting the process, there's a fair chance enough of these things could be worked out that MS/would/ be able to pull it off, but as it is, it's looking really really tough for them, at least this round. I don't think anyone expected that, on either side.
Unfortunately, I'm not sure what the vote at the international level must be, only that the individual nations need a 2/3 vote, and that all nations' votes count equally at the international level.
[M]y university has authenticated logins to access the network [but] the bans for copyright infringement (40 days) and exceeding allocated bandwith are based on MAC addresses. Which, since my school is also very geeky, has the effect of making the ban simply for show
That's very cool! =8^) Glad there's still some of that around.
Every time I reboot and reconnect to my ISP, I use a new MAC and therefore get a new IP (privacy... sure, the ISP can trace it, but anyone else has a bit tougher time without the ISPs cooperation), due to a little program called macchanger integrated into my bootscripts
I'm not sure exactly what you think you're getting 'privacy' from, but you know that your ISP looks at the MAC address of your Cable/DSL modem, and not that of your network card, right?
You/did/ note that I said the ISP could trace it, right? It's privacy (of a fashion) from others, however. Unavoidably (unless I use TOR or the like), all the web sites I visit get my IP. Great, that's the way they get content back to me, but there's no reason they need an unbroken profile of me at the same IP going back months, unless I choose to give it to them by allowing cookies or the like. At a few sites (/. comes to mind) I do, and even provide an even closer ID-ed profile by actually logging in, so it's linked to whatever info I provided when I setup the login. plus the profile of whatever posts I've made while logged in.
With a bit of work and some cooperation between various entities, I've no illusions that anyone sufficiently motivated, particularly the gov or in many cases someone pretexting, could link it all together, even without the cooperation of my ISP, due to my IP appearing in various logs that link to web posts I've made, in emails and news posts, etc. Certainly, my ISP has the info to link even closer and with less effort, but this isn't so much about them, as about the Googles and others of the world that would otherwise be able to assemble a profile quite easily based on seldom changed (while my cable IP is officially dynamic, it changes maybe once a year or so if I don't change the MAC, perhaps less often than that) IP info alone. With cookies set to session-only and scripting off by default, and with privoxy setup to block or randomize (within limits) various other conceivably trackable headers (if-none-match, blocked, if-modified-since, randomized within a range, etc), IP tracking remains a rather practical way to profile me. Changing it every week or so, when I reboot for the latest linux-rc or whatever, chops up that profiling into relatively less personally revealing short segments.
Now, I DO use a relatively uncommon browser by default (Konqueror), and deliberately do NOT hide its user-agent. The IPs I get from my ISP all contain the city in the reverse lookup, and while the subnet does change within a group, if a web server operator correlates user agent with IP address, chances are they could still ID me fairly accurately, no illusions there either. However, the costs of doing so are a bit higher and the reliability rather lower, and I judge the tradeoff in publicizing the fact that not everyone's using the big four (IE/FF/Safari/Opera) worth it, thus the deliberately NOT hiding that info.
So anyway, yeah, it's a privacy thing, but I'm not fooling myself on its limits, either from the ISP, or for a sufficiently motivated server-op on a server I visit regularly, pretty much anyone else either. It does make their work harder, however, and the results a bit less reliable, which is what I'm after and all I realistically know I'm going to get, without onion routing or the like, anyway.
TFA mentions that Stanford and other schools charge high "Reconnection" fees after they block your MAC for sharing files. Why don't they just do something like that and make a load of money?
No, TFA does NOT talk about blocking MACs, because that would be fscking stupid. Every time I reboot and reconnect to my ISP, I use a new MAC and therefore get a new IP (privacy... sure, the ISP can trace it, but anyone else has a bit tougher time without the ISPs cooperation), due to a little program called macchanger integrated into my bootscripts. Its site http://www.alobbs.com/macchanger says there's a similar program, SMAC, for MSWormOS. Even without that, a $5 new NIC is a new MAC.
Rather, presumably, these schools use some form of authenticated login, with school accounts. All they have to do is shut down the account and refuse to open a new one for that student (tracked after all by student ID, they change that, they lose all their credits and get to pay all sorts of new money to the school to start over), either at all (KS) or until the hefty graduated reconnect fee is paid.
Of course, there's always logging in with someone else's auth, but if they get caught doing that without permission, in most cases it'd be expulsion for cracking, and pretty much rightly so, IMO. If they have permission, then at minimum, the one lending them that permission is risking/their/ account, for the same reasons.
It'll be interesting to see how this turns out, and whether they change the wording to/unauthorized/ copyrighted content before they get sued on that wording or not. As TFA states, however (and this it/does/ state), the practical effect as already being seen elsewhere is likely to simply be the widespread popularization of darknets. Sure, some will get caught, but kids have a way of believing they are almost invincible and being willing to play the odds, so it'll keep happening, because it simply isn't practical for them to bust and enforce on 75% of their student body.
The ACLU said Wednesday it has given cameras and training to about 10 residents in north St. Louis, a higher-crime part of the city.
And:
Former St. Louis Police Department Sgt. K.L. Williams is overseeing the training process for residents who will receive a camera.
Williams said the training sessions last a few hours. The primary focus of the training is to teach participants how to video tape police activity from a safe distance without interrupting arrests or searches.
The citizens are not there to interfere with any police contacts, Williams said.
ACLU spokesman Redditt Hudson said the program will also include free workshops to teach residents about their constitutional rights when approached by police.
So, part of the training, conducted by a former Police Sgt. from the same city, is specifically how to avoid being in the way while taping. (The zoom others mention should come in handy.) There's strong emphasis on not interfering, with the training being delivered by someone that should know the situation really well. In addition, there's training on constitutional rights under the circumstances.
Since they are working closely with the police in setting this up, both the police and the citizens doing the filming should be aware of the situation, that the citizens know their rights, and that they should know how to stay out of the way. There's little doubt that both sides are aware of the national news aspect of the situation as well.
The police will likely be on their best behavior, and there'll be nothing bad to film. However, far from being a/bad/ thing, a drop in (allegations of) abuse will demonstrate the program is working -- preventing that abuse. OTOH, if it shows abuse, well... hopefully it/will/ make the news and the situation will change.
> The Linux kernel, for better or for worse, is going to be stuck at GPLv2.
What you said previously is AFAIK correct, but this conclusion doesn't necessarily follow.
1) Until Linus changed the default kernel license to GPLv2 only, submitted code would have been GPLv2 or later by default. That's a lot of code, and it's the older code which would presumably be the most problematic in terms of tracking down authors to even discuss license changes.
2) Note the "by default" in the above. Any GPLv2 compatible licensed code can be merged, and there's a significant amount of code that's under 3-clause BSD or similar "less strict" license terms, or specifically GPLv2 or later, even if merged after the default changed.
3) Assuming an agreement between the major contributors to head toward GPLv3, and not to merge additional GPLv2 only code, a huge portion of what remains could be switched to GPLv2/v3 dual license "overnight".
4) Finally, some contributors have merged code with a "GPLv2, but I give person X (where X is generally Linus, Alan Cox, or similar well recognized major kernel contributor) the authority to make licensing decisions in my stead" type license/agreement. Obviously, if the assumption of #3 is correct, most or all of this code can equally be license switched overnight.
The above four categories would cover, wild but reasonable guess, 2/3 of the code base. Given the rate of kernel code churn, with no additional effort, only changing the default for new code to GPLv2/v3 and not accepting anything not compatible with both, within say five years, half to 2/3 (again, reasonable WAG) of the remaining code will be taken care of, simply due to code churn.
That would leave, using my for sake of argument "reasonable WAGs", ~11% of kernel code as needing further attention. Of that, it's fairly safe to assume half of the contributors will be easily found and readily agree to dual license their code GPLv2/v3.
That leaves ~5% of the current codebase as problematic. If there's anything the Bitkeeper thing demonstrated, it's how fast the kernel community can turn on a dime, code-wise, if it's in their interest and common agreement to do so. If over that same five year period, the first two years little is done besides "watchful awareness", waiting to see what areas change on their own, then years 3-4 can get increasingly focused on changing the remainder. That simple act of increasing focus is likely to half the remaining problem code again, so we're now down to perhaps 2% of the current code base for the final year's attention, with probably two releases focused almost entirely on license based code rewrite (staggered with 1-2 regular releases between them). With the code churn numbers Andrew has tracked and discussed several times since 2.6.0, 2% code base rewrite is certainly possible.
After the last GPLv2 only code has been removed, the kernel would be fully GPLv2 AND v3 compatible, and it would be legally possible to drop the GPLv2 side of the license, leaving only GPLv3 as the default for further new code, and GPLv3 compatibility fully required.
Thus, it/could/ be done, but it would be a HUGE effort, would require the general consensus agreement of nearly every one of the major contributors since the default changed to GPLv2 only, and would take some serious time. I expect it could actually be done in less than five years if required by say patent attacks or the like, but believe it's still safe to say it'd take two, minimum, and likely at least three. Five, however, should certainly be doable, PROVIDED there's consensus agreement that it's needed.
Linus doesn't hold copyright on all the code in the kernel, certainly, but he's certainly the pivotal consensus leader. If he doesn't think it's worth moving the kernel to GPLv3, it simply won't be done. If he DOES decide it's worth doing, THEN it's a question of whether a consensus agreement can be reached with all the other major kernel contributors as well. It's no
Mine was Qworst not ATT, but the story sounds familiar. I moved (a few blocks), they knew enough about my connection to see I had DSL and ask if I wanted it moved too, but they apparently couldn't tell the new location didn't have a drop.
It took them several weeks, at a week to reschedule each time, to FINALLY get me even a voice line at the new location, that was SUPPOSED to be hooked up the same day I moved and my previous location was disconnected. They had all sorts of excuses, including the one week where the monkey (um, excuse me, technician) put on the ticket that the location was a vacant lot!!
So after several weeks without even a voice line, I finally got that, and started the runaround on the DSL. After another month or so of calling back every few days, I finally got the straight story. It was the same CO and DSLAM as I had had at the previous location, but due to their monkeying around, they had given the DSLAM slot to someone else, and there was a waiting list months long, but/only/ three months to go until they'd be upgrading, after which I should have no problem.
That's when I called Speakeasy and had them sign me up. 15 days later, I was up and running, and that was after an extra day because the telco monkeys (um, technicians) robbed the reserved dry pair for the DSL and put someone's voice line on it. However, unlike their/own/ service, they were under FCC monitoring on this as cooperation with the competition, so instead of taking a week to reschedule a single monkey to try again as they did with their own service, they were out THE NEXT DAY, with not one, but TWO techs, real techs not monkeys this time, and they had it straightened out in no time.
So if I'd have called SE when I first moved, I'd have likely had DSL before the telco monkeys got their act together enough to even get me a voice line.
It's little wonder that as soon as the cableco (Cox) Internet came around, I switched from DSL and got rid of the telco's providing that, and a year later, when the cableco offered phone service, I jumped on it, and severed my last business dealings with the baboons at the telco. What was pitiful was the letters they kept sending me saying they wanted me back. Cox isn't perfect, but it's DEFINITELY been better than the collection of baboons the telco had doing things around here! (FWIW, Cox gets far better ratings than Comcast does. I read about all the stuff Comcast pulls and am glad I'm not choosing between baboons and orangutans, as it looks like I'd be doing if Comcast was the local cableco.)
The users decide the fate of Linux... now and when Linus dies. They do so by deciding which of the Linux trees they use, if they compile it from source, or by letting their distribution choose, if they use the distribution kernel.
There's nothing saying that the Linus kernel is the only one now, and in fact, it's not. However, "mainline" has been defined by common usage to refer to the Linus or Linus blessed maintainer kernel, with other trees being lessor forks.
When Linus "retires" (he doesn't have to die, tho that would do it), as now, the choice remains with those that do the using. Even distribution kernels get used by more or fewer people, thus affecting the choice of the community as a whole.
In fact, it hasn't happened yet, so the question has yet to be resolved. However, some fairly safe predictions can be made based on what has happened with other projects, xfree86/xorg, gcc/egcs/gcc, cdtools/cdrkit, etc. Despite the fact that there are few legal restrictions preventing forking, there are very strong cohesive forces as well, and in general, the community tends to form a strong consensus agreement and for the most part, all end up going the same way, not because they have to, but because it's more efficient that way, so forks just tend to die out until there's only one dominant candidate left.
Now, Linus tends to have a generally uncommon mix of talents for a geek. He's a great coder but certainly not the greatest. However, his strength is his social consensus building skills. Very few at his technical level have that kind of social skills, and it's that, as much as anything else, that has made Linux as a kernel the dominant force it is. It would therefore be a SERIOUS loss to lose Linus, and I expect the community would be rather weaker for some time as a result, but it'd survive. A previous reply already mentioned Alan Cox. There's also Andrew Morton. At this point, I'd guess one or the other of them would take the informal (because that's what it is, even with Linus) lead, likely they'd work in tandem much as Linus and Andrew do at this point, discussion on LKML would be even more lively than usual for a few months, a few distributions or kernel trees might diverge a bit further than usual for awhile, but life would go on. Once Linus was gone and that was a fact, consensus would fairly quickly build behind a new leader.
What's a possibly more interesting question to me, is if the kernel doesn't eventually move to GPL3 (it could, but it'd take a definitive agreement from major contributors to do it, and several years, during which an increasing portion of the code would be dual-licensed GPL2/3 until the last of the GPL2 only code was removed/rewritten, so the GPL2 could be dropped), and the GNU tools do (a given), along with the OpenSolaris kernel, what might happen then, especially if the patent thing begins to force the issue on GPL2? It's possible, tho too early to predict, that GNU/OpenSolaris may become the new Linux, with Linux-the kernel eventually sidelined (/not/ dead), much like the various BSDs today. It could certainly make for an interesting few years in FLOSS-land, that's for SURE!
The logo... Let's just say I think letters 2-4 stand out a bit much, and the first word that comes to mind is NOT fUNToo. =8^P Of course, if that's the effect you were wanting, it's certainly in the tradition of the GIMP, BitchX, C.L.I.T., etc, and I'm not one for being PC just for the sake of it. Just be aware of the word association it invokes, is all. You're probably more aware of the doors it might close than I am. If you are and it was deliberate, great. =8^)
The review, from this Gentoo/~amd64 user's perspective... I'd agree with some, not all. Looking around, the biggest issue I see is that there's now two different "installer handbooks", the general Gentoo Linux handbook and the 2007.0 handbook, plus the quick install guide (and tips and tricks, and alternate install guide, and...), and it's not going to be immediately clear to a newbie if he's reading the right one or not. Then when they go looking for help, they'll likely just refer (or be referred) to "the handbook", making things all the/more/ confusing when the newbie and the trying-to-be-helper are reading two different things. (I just went thru that myself, trying to figure out which one you read. I still don't know. Good thing you weren't asking for help! =8^( )
So after I finish this, I'm headed over to the docs list for a suggestion. For 2007.1, what about a single one-page document, listing all the installation docs with clear pointers as to what is specifically covered in each one? As some of the existing docs list several of the others, replacing the several references with a single but more prominent reference to a single list, should actually reduce total line count, I'd imagine. That should get your quick-install suggestion shown more prominently, plus provide stronger hints on exactly what one/should/ be reading for any specific purpose, and why.
I think that covers, directly or indirectly, most of the issues you had, including networking, the lack of stages, and the low prominence of the quickstart guide, since all three are covered, but at present it's confusing enough I can't really blame anyone for not seeing the coverage.
Anyway, as I don't believe I've had a chance to say it to you before, thanks for the distribution. For some of us, it's really almost perfect. Well, as perfect as reality gets, anyway, despite the various negatives, which from this viewpoint end up seeming rather minor when compared with the positives. Unfortunately you apparently experienced that old saw, "you can never go back", because even if you do, it's not the same. (As I'm sure you know, the events triggered some changes, but anyway, it's history now.) Still, disagree tho you might with some of his choices now that he's grown, I think you've every right to be proud of your "kid", now that he's growing into the equivalent of a young adult, as tho there have certainly been growing pains, he's turning out to be quite a responsible young member of his community. =8^)
Or do you really believe that people are more interested in Paris Hilton's jail term than in the president wiretapping them? Those Lindsay Lohan stories really must represent the public's true interest. Look! Look at the funny monkey! Look, Britney has no panties!
Keep in mind that at least where TV is ad supported, it's not necessarily the number of folks interested, but the/quality/ of folks interested.
Ask yourself this, because you know both the ad execs and TV execs do: Given the typical geek or scientifically minded individual against the typical "OMG, Britney's got no panties!!111one!, which one is going to be EASIEST FOR THE AD BROKERS TO PROGRAM TO BUY THEIR SH*T, even tho they don't need it and it wouldn't have even occurred to them to want it without the ad, even tho they're just getting to the point of owing less on it than their only two year old car is worth, etc?
How many people that actually think for themselves have to be in the audience to make up for just ONE "programmable zombie"?
Want to know why there's so little worth watching on TV, why the reality shows and celeb news and the like seem to be the "gray goo" subliming everything in their path? Now you know. It's because the folks that watch that sort of crap are the best, the most easily programmable, ad targets in the world!
Again,/how/ many folks that can actually think, and thus aren't so likely to fall for the ads, does it actually take to replace one "programmable zombie"? 10? 50? 100? No/wonder/ there's so little decent on; so little that appeals to folks that can actually think, and worse yet (for the advertisers) actually/like/ to think!
It has been nearly a decade now since I dropped TV. I found it was a natural process. I was spending more and more time on the computer, something I could actually interact with, and on the net, interacting with others, and less and less time staring at the stupid boob tube. I don't really miss it, save for the news channels when something big goes down. Sometimes I'll catch some at a friend's house or something. A few programs are acceptable, but the ads... the first time I see them might be fine, but the moment they start repeating, I often find myself driven away, to find something else to do, something less insulting to my intelligence, my ability to actually research what I buy and make up my own mind, getting the required info from sources that actually respect me as a person with my own needs and wants, not as a "consuming machine" to be programmed to buy whatever's being pushed at me the hardest.
The usual IANAL and etc disclaimers apply... I'm simply a free software user with an interest in, and thus a bit of acquired knowledge in, this area.
Patents != trademarks != copyright.
It's not unusual for companies owning patents not to enforce them right away, and failing to do so doesn't appear to invalidate them. Cases in point are the Unisys GIF patent and the Fraunhofer/Thomson MP3 patents.
Unisys didn't enforce its GIF patent (on compression, IIRC) early in the Internet age, thus allowing it to become the early standard for limited bit-depth lossless graphics. They then attempted to enforce it after it had achieved critical mass on the Internet, with mixed success. IIRC, they attempted to collect on GIF encoding only, as decoding was apparently possible without breaking the patent. However, it was still a tax collected on GIF authoring, and as such a pain. The PNG specification was developed as a workaround, but limited/crippled support from MS in IE limited the popularity of PNG.
Similar happened with MP3 patents, with some differences (of course). MP3 dominance can in part be attributed to the fact that Fraunhofer/Thomson haven't pursued the free software based LAME encoder (among others, LAME's quality and popularity has however been a big reason for the popularity of the format), and have by stated policy declined to enforce the patent on individual users, sticking rather to enforcing the patent on proprietary/commercial (en/de)coders. The threat however has remained, and continues to be a pain for free software based MP3 support, in particular for commercial distributions such as Red Hat and Ubuntu, the reason MP3 support typically requires configuring or at least activating a "non-free" repository.
Fortunately, however, patents, unlike copyright, isn't in effect "forever", only painfully long (20 years in the US). Thus, waiting for a technology to become popular before pouncing on it and attempting to enforce patents that may apply to it has the practical effect of running out perhaps half the clock, a decade or so for the technology to become popular, leaving only a decade to attempt to collect patent royalties. The last three years will be particularly hard to collect on, as simply playing the waiting game becomes increasingly practical, so the royalty values begin to go down dramatically. That leaves a collections window of 7-12 years for anyone trying the "wait until it's standardized/then/ attack" strategy.
The GIF patents expired in 2003 or so, so GIF is now an unencumbered technology once again. MP3 hasn't yet expired, but the clock is definitely ticking. According to Wikipedia (so good place to start but do more research if you are planning on relying on the info), the related patents expire between 2007 and 2017 in the US. However, the MP3 standard being published in 1991, with 2011 being the 20-year mark beyond that, enforcement of patents on MP3 itself extending beyond that remains in doubt, with recent legal developments likely somewhat strengthening the effect of the 2011 drop-dead date, altho that is somewhat counteracted by at least one new claimant stepping forward recently. Still, 2011 will be a very big year for MP3 technology.
Of course the MS patent claims, as with the claims of most major patent holding companies, are somewhat different, in that they are broad-based and generally subject to more of a continuing development effect. That is, it's not a single technology or a single patent in question, but a collection of patents on multiple technologies. Over the course of several years approaching a decade and longer, while some patents will expire, typically other new patents are applied for (and some granted) to replace them. Thus, the problem becomes an ongoing one, applying to anyone unwilling to continually settle for minimum 20 year-old technology.
All that said, the doctrine of laches, as mentioned by others, may still apply, tho its strength in regard to patents doesn't seem to be as high
Slashdot Mirror
Incorrect, unless you are donating your entire performance or have otherwise specifically negotiated a "discount" fee.
Rather, that hour of paperwork is factored into the cost of doing business, thus raising the performing rate somewhat for the hours you are paid for. As such, it's indirectly paid, in the same way the mail and web accounts bundled with a normal consumer ISP account are indirectly paid, altho some may call them "free". In the same way that the ISP isn't there as a charity, and must recover costs, thus raising monthly fees to cover the cost of providing all the "bundled" services, so unless you are operating as a charity with your performances, as a cost of doing business, your performance fees also figure in the time necessary for filling out that paperwork.
As another, actually more direct comparison, consider the "unpaid" time many workers spend commuting. Under normal circumstances it's self-evident that they are doing it for the money, and as such, that "unpaid" time is really "indirectly paid" time, as they have obviously figured it into the cost of doing business or they'd not be employed at that location at that wage, but rather either somewhere closer or at a higher wage, in ordered to cover the cost.
So as I said, unless you are doing it as a charity (which the whole gripe about being unpaid for the paperwork time would imply is not the case), it's really indirectly paid time, because it's figured into the compensation as a part of doing business. Were it not so, you'd either be demanding higher pay, or working elsewhere, as otherwise, taken a whole, the pay would not be "worth it" to you, and you'd be doing something else with that time instead.
I do agree with the point, however, and am glad you took the time to post it. It'd be nice not to have this cost of doing business, or to reduce that "hour" to "10 minutes". Unfortunately, that's not likely to happen immediately, or from this single case alone, altho it is likely to help keep that "hour" from becoming "two hours".
Duncan
That's one comparison and it's reasonably valid, but it's not the one I had in mind. Rather, I was thinking desktop/workstation, but sorted more by age. Linux is known for its ability to give old hardware new life. While I removed any trace of proprietary OS from my systems some years ago, I've recently had a bit of experience again with them as I've a bit of a reputation as a computer guru and some folks have needed password resets and the like done.
One I had to work with was an old half GHz machine with 64 MB of memory, running (what I refer to as) "eXPrivacy". It basically wouldn't run the recovery LiveCDs (STD and INSERT) I had downloaded because it simply didn't have enough RAM. Well, it booted to CLI mode and I could do a bit from there, but it wouldn't load X, as it said X required at least 64 MB memory and as this was a liveCD, it was running out of RAMDisk and using part of that 64 MB for that. FWIW, the desktop environments they tried to run were IceWM and something similarly light, I forgot what. Sad to say I didn't have a lot of luck with this computer (which I was trying to virus scan), because I simply wasn't familiar enough with the territory to know how to accomplish what needed done without enough memory to load X and get at the normal documentation and set up the network, etc. As it wasn't my machine I didn't really know the territory well enough to safely do a lot on my own, I didn't try shrinking the main partition to give me enough swap to work with to do what I needed to do. The owner took it back and I believe had another "friend" reinstall whatever pirate stuff they had to work with.
That's why I gave a higher figure for LiveCD use. The half GHz, 64 MB machine would have worked well enough with IceWM installed locally, so it wasn't trying to run off RAMDisk and had some swap space available, but I was trying to run off LiveCD/RAMDisk, and it just wasn't working. 92 or 128 MB would have worked much better.
The second machine I had to work with (password reset this time not malware, legit as I knew the guy and it was his data) was again eXPrivacy, but a bit higher speced, 1.2 GHz or so, 384 MB RAM. Both recovery LiveCDs worked MUCH better on it, and even off LiveCD, it ran rather noticeably faster than the eXPrivacy Pro it had loaded. It could have handled a heavyweight desktop if necessary, but I'm sure it was much more responsive with IceWM and etc.
Thus the minimum decently workable memory for a reasonably light (reasonably modern, not Win9x era) desktop LiveCD is going to be 92-128 MB, 64-92 MB running native installed to disk with swap. It'll be rather higher with either of the full heavyweight desktops -- 256-384 MB is probably about the low end I'd consider reasonable to work with, altho a lot can be done with swap and 128 MB might be barely usable, if it's absolutely necessary.
The point there is that for a lot of folks running second hand hardware, this level of resources is what they are working with.
Basically the same under the hood? Let's just say I disagree. GNOME's C based, KDE's C++ based. KDE's much more integrated, designed and implemented with much higher reuse of components (at a cost of very high and cross-interlinked dependency requirements, much higher and with more interlinked complexity than GNOME, even to run a single app or two in another desktop environment -- compile these things and all updates from source as I do on Gentoo and you KNOW these things =8^/ ) There are other differences as well with the current generation, dbus vs. dcop, et
Actually, I was rather surprised at how easily the FSF let off Novell on that one, although it was arguably because they believe they entrapped MS in doing so. (It'll take a case to prove that one way or the other, but it's an interesting legal maneuver regardless.) Still, RMS was sounding very fair even before anything about forcing MS' hand ever came up, suggesting that it might be best to grandfather in existing agreements -- which pretty much meant Novell only at that point.
So I don't believe you can fairly lay that at the FSF' feet. The FSF position in fact looks rather uncharacteristically compromising, to me, compared to the many of the Novell slaggers.
Me? I'm a Gentoo guy now, and before that, hadn't tried SuSE because I didn't like their "non-free" no commercial use license on Yast and the like (an approach it should be pointed out Novell quickly changed to full GPL, BTW; they get major points here for that, but I was already switched from Mandrake to Gentoo by then, and Gentoo's far more my style). So it's nothing I'm directly involved in, but I certainly thank them for their contributions, the same as I wish they hadn't done the MS thing, but understand why they did it. So basically as a GPLv3 supporter, I'm taking my queues from the FSF on this, and the FSF gave them a pass, so I'm willing to do so to.
As for Sun, they've been quite involved in the formation of the GPLv3, and I'd not be surprised to see them ultimately dual license OpenSolaris CDDL/GPLv3. If they do, things could get rather interesting... as it could quickly be adopted by the FSF in place of the long floundering GNU/HERD and take the place of both it and Linux as the darling of the FSF. If the RMS predictions on Tivoization, patents, and digital restrictions management even come close to true as well... and Linux hasn't at least started the switch to GPLv3 before it all starts coming down, GNU/OpenSolaris could very possibly be the successor to Linux, and ultimately be the one to achieve that "world domination" that the Linux folks keep half-joking about.
Of course, that's a pretty long set of successive still long-shot ifs there, and while the FSF and friends would welcome a GPLv3ed OpenSolaris, most of the other IFs there aren't too pleasant to contemplate, so I think it's safe to say few hope it all happens that way, but it's possible.
Duncan
Not me! The problem is that in this case a single size does NOT fit all! There's a need for at least three and likely five "environments" on the desktop. Here's how I figure.
The first two are the "big two". Fairly heavyweight, the problem here is that the approaches differ and "never the twain shall meet." Then there's XFCE, lighter weight while still being rather featureful, and for the really "resource challenged" (read as <384MB memory "LiveCD", <256MB memory running of of writable media, these days, or 92MB/64MB if you wish to be really conservative), something line IceWM. Finally, some find ION type WMs more to their liking. For them, the standard WM/environments simply aren't organized or efficient enough, and can never work.
Focusing again on the "big two", the problem is as follows. The GNOME approach (characterized from the opposing viewpoint, and obviously drastically simplifying) seems to be that in most cases there is "one single best UI choice", and that if there's a split as to which way is best, it's simply because the "correct" UI presentation hasn't yet been found. Their approach to customization is minimalistic, the less setting there are to confuse the user, the better. The common complaint from the "control freak" (me) and/or "power user" and/or "developer" (Linus) is that tools and choices that should be there, tweaks that should be possible, simply aren't... at least from the GUI... and this they/we find EXTREMELY frustrating!
The perfect example is the UI elements color chooser applet. Even MS has one, yet GNOME for years somehow didn't find it necessary. I'm not talking about just a color chooser applet, sure they had that, but one couldn't use it to do something as simple as choosing the background and text color of a command button, without choosing an entire theme and changing all sorts of unrelated stuff at the same time! I'm not sure if they ever got one or not (at least in GNOME-core, I must assume someone has implemented an option applet to do it), but from my viewpoint, that's so basic a required functionality that I can't consider a desktop environment even half developed without it! Of course, in KDE, it's the colors control panel applet, control panel, right where one would expect it, shipped in kdebase, again, right where one would expect it. It has existed since at least KDE 2.x.
Contrast the "if you don't find our imposed choice best you obviously don't know what's good for you" approach of GNOME with the KDE approach, which could be characterized (hopefully even handedly simplifying/exaggerating) as "if there's a choice in UI behavior, program all possible choices and expose them as an option for the user to choose." The common complaint from the "I just want it to work" crowd is that all those options are confusing and just get in the way of actually getting things done. They find this confusing and frustrating too, I suppose in equal measure to the power users and etc trying to work with GNOME.
The problem is that in terms of basic UI approaches, as I said, "never the twain shall meet." Sure, there can be some working together to make an app from one desktop work well on and function somewhat like the other if it finds itself in that environment, and there are projects to that end. However, I've come to realize that the two approaches are both necessary and fill a need, and that if either desktop project were to suddenly collapse, the developers on the other would likely be first in line donating to get a new one started! Why? Simply this. As long as the folks taking the other approach have their own sandbox to play in, they won't be trying to change the rules in and screw up ours! I'd hate to have GNOME users and devs trying to "simplify" KDE to their liking, removing all the tweaking ability many KD
There are standard SIP clients for all the major OSs. It's a standard, after all. There are also standard SIP hardware devices, from ATAs (analog telephone adaptors) in both end device and router versions, to Ethernet based SIPPhones (including PoE, power over Ethernet, so single cord) to cordless wifi devices, to computer card phone adaptors, available from several different manufacturers and multiple vendors. There are also both open (Asterisk) and proprietary (Cisco, among others) VoIP/PBX implementations as complicated and featureful as you care to get.
I recently switched to 100% VoIP here (I can't justify the additional cost for cell service, so this was from standard telco land-line). One of my big requirements was everything I got was SIP-standard, no-lockin. The going (US) rate is ~$25-30/mo including all taxes/fees, or prepay a year for $199 plus fees (which is what I did), which works out to $16.58/mo, and my fees are $2.50/mo, so I'm paying <$20/mo total, by prepaying. That includes at least US/48 as if it were "local", plus incoming. The differentiation between providers is that some provide up to 25-nation "local" calling for that, while others include a few extra features -- altho all the "standard" features the telcos like to charge extra for, caller-id, voice-mail, etc, are included at no additional cost by nearly all providers. Since all the folks I call are in the US, I chose the extra features, including such things as selective announcement voice mail (so my friends get a different greeting than ordinary callers, can be handy at times) and scheduled automated wakeup/reminder (b-day, anniversary, etc) calls -- no additional cost! =8^)
If you do mostly net calling, as I think with Skype, you can get that for free. If you need incoming phone only, that's available with a local number in many cities in the US from $2/mo, if you shop around. Outgoing only, available from $10-ish/mo. unlimited or 4 cents a call (NOT per minute, per call) or a penny a minute, both without monthly fees, just usage. (The 4 cents a call thing is to the US, but provided by a company in Norway, Vyke.com... I couldn't get my US credit cards to work with it, unfortunately.) There's also 500-ish minute accounts and the like available, and 35-nation, regional, and nearly worldwide "local" calling plans, for those that need them. "Unlimited" does in the cases I've been talking about refer to "residential" service, but there's also commercial service, without residential use restrictions, available, from $30/mo or so, and fully unlimited, wholesale resale and phone bank and etc services allowed, at per minute rates, of course depending on provider.
I went with a two-line ATA/router, which plugs in between my cable modem and my network, and can handle two separate SIP based phone accounts. The two phone lines (two separate jacks, two separately controlled SIP accounts) plug into it pretty much as they'd otherwise plug into the telco NID at the demarc point. The adapter cost $57 -- again, I elected to buy my own unlocked SIP standard based equipment, for additional flexibility and no lockin. I bought a grandstream, but there are other brands with a variety of features and at a variety of costs. Mine is about the size of a cigarette pack -- which surprised me as I was expecting something about three times that size.
** I did have to go to the net to buy it, as everything the local brick and mortar stores seemed to offer was locked to one provider or another, generally Vonage, Lingo, or Skype (the latter proprietary not standard SIP of course). However, going local rates for the locked versions was about double what I paid ($57 as mentioned) for my Grandstream on the net, so it was well worth it.
Since I no longer have a regular land-line, I bought a (separate, again standard/ordinary) UPS to power my ATA, cable modem, and cordless phones, so I have phone service even when the power goes out, as long as the cable internet stays up (and it should be fairly reliable as they run their own phone service in competition with the telco, too, and have battery backups for it).
If you released code under a dual license such that the part that was GPL before is now dual licensed, you have violated the license on the GPL code (assuming you linked to it and etc. and etc, thus the "mere aggregation" clause didn't apply), unless of course you got the permission of the author to do so.
/can/ legally do as long as the licenses are compatible is release the combined work under your own choice of license (including dual, but you aren't obligated to), acknowledging the license on the component, with clear delineation of said component and with its license reproduced therein, so there's no mistaking what part of it is subject to which license.
Now what you
You may also release your own code under a non-compatible license, but that restricts distribution of the GPL component, so a user would have to procure that separately and combine them himself. That's questionable, but has been to this point tolerated, as with the NVidia and ATI kernel modules, for instance. (With at least NVidia, they have a buffer layer as well. The buffer layer is MIT/BSD licensed and as such is compatible with both the proprietary license of the core binary-only module and the GPL of the kernel, and only the buffer code links to both. Thus their proprietary code doesn't directly link at all to the GPL code, adding another layer of safety, particularly since it's said to be the same as the core of the MS Windows driver and thereby cannot be be easily argued to be derived from the GPLed Linux code.)
Back to the main case under discussion, answer me this. What's the significance of the dual license, then, if they can't be "alternatively" split? It simply doesn't work, because by one interpretation, both would apply and the two aren't that compatible, so ti doesn't work, by another, the stricter would apply, so source would have to be provided, and that would offend the BSD folks and definitely anyone that tried to use the source in closed code, and by a third, equally as valid as the others, the liberal case would apply, in which case it might as well be BSD only. They are all three equally valid, so none can be said to apply.
Looking at it the third way, as it seems the BSD folks wish to do, if it were made a component of GPL code and improvements were made, then proprietary coders could take that source and do with it as they wished because the BSDL was still attached, which would violate the GPL. Thus, where's the use in dual-licensing it in the first place, since the GPL can't be held to apply with or without the dual license?
That doesn't work for the same reason the reverse doesn't work. GPL folks can't demand code improvements from proprietaryware fols that might have used the dual licensed code. That's the second case. The first case is that both apply, which isn't logically consistent either since the source can't at the same time be shielded as the BSD allows and provided as the GPL obligates, so all three possibilities of the AND case simply fall apart.
Thus, the only possible logical interpretation is that the OR case applies. If the OR case applies, there's no problem, because OR was chosen. It's not rewriting the license of someone else's code, because they wrote it that way in the first place, specifically allowing the split to be made, both because they used the term "alternative" and because there's no other possible logical construction.
Seems as if just as some in SCO didn't understand what they bought, so some here may not have understood what the license gave away.
Duncan
That's my thought as well. If it's BSD AND GPL, it either can't be distributed at all, because the two have terms that can't BOTH be satisfied, or it reduces to one or the other, BSD if read liberally, GPL if read conservatively. If it reduces to GPL, the BSD folks are going to be rather unhappy. If it reduces to BSD, there's no point in the dual license in the first place.
Therefore, the only LOGICAL conclusion is OR (regardless of the fact that OR is what alternatives means). The BSD folks wouldn't be (and demonstrably aren't) comfortable with folks demanding source, so they are obviously OK with dropping the GPL side. What's wrong with the GPL guys therefore dropping the BSD side? (Note that interpreting it as explicitly requiring continuing the BSD license would return to the AND case above, which in the case of the specific dual license logically falls apart.)
Duncan
Yes, you can. That's what dual licenses /do/, allow you to use either one.
After all, what would be the point of the dual license if neither one could be dropped? Wouldn't that be effectively exactly the same as the BSD license? Or taken the other way, wouldn't that mean that anyone could demand code under the terms of the GPL?
It can be pointed out that the BSDL already gives GPL folks the right to use the code under the terms of the BSDL (that is, keeping the attributions and BSDL in tact on that specific code, but in a work licensed overall under the GPL). Thus, the dual license don't change anything there, if both licenses must be maintained intact.
Conversely, if both license must be maintained intact, then anyone can demand the sources or that redistribution be stopped, under the GPL side, which isn't going to fit the intent of the BSDL very well.
Alternatives mean just that. See the Trolltech/Qt and MySQL cases, among other examples. Neither of those requires that the GPL continue to be propagated on the proprietaryware side, nor that the proprietary licenses continue to be propagated on the GPL side. Some on the GPL side continue to propagate the other license downstream as well, so that the end user may choose, but not because they have to.
Duncan
You say it makes the code less free. I say it makes the code more free, because it guarantees it will remain free.
/change/ the freedoms applying to the code. I don't see how there can be argument on that, because regardless of whether one believes it's more free or less free, it certainly changes the applied freedoms.
Perhaps we can agree on a statement that it would
Duncan
Except for one thing: As the author of the new code, you /cannot/ be forced to relicense your own (new) code. You CAN be forced to choose between doing that and ceasing redistribution of the GPL code (and therefore the combined work); you /may/ be forced to pay damages for distributing the GPL code outside the license, but you /cannot/ be forced to relicense your own code. (The extreme case where you forfeit your property due to failure to pay the court ordered damages due to the unlicensed distribution is separate, as that's not forcing you to relicense your code due to the violation, but simply due to failure to provide suitable other assets to pay the court imposed damages.)
That's one thing MS and the others deliberately fail to mention. Even if they took GPL code, they couldn't be directly forced to release their own code. The could choose to stop distributing until that portion was rewritten to be non-infringing, and pay appropriate penalties instead, and I'm sure that's what they'd choose to do unless it was something trivial. If it took them a few million dollars to rewrite the offending code in 30 days, skipping the usual test regime if they had to, during which they couldn't distribute and were thus losing millions per day, they'd do it. Of course, better to not be found in that position to begin with, but there's nothing saying they'd have to open the code they created around what they "borrowed", as long as they were willing stop distribution until it was rewritten and pay the damages in the mean time.
Duncan
You obviously didn't RTFA. The IR beam and its reflection simply serves as a lock on the positioning of the eye in space, allowing a /relative/ comparison of the position of the pupil. Thus the reflection of the IR beam gives you nothing on its own. Even filming the motion of the eye won't give you an absolute fix on the password (tho it could significantly narrow the brute force search domain), since it's looking at a virtual keyboard to do its "typing", and you'd have to have a fix on where that is as well, in ordered to know whether the movement was a single key or a whole keyboard away.
/else/ for the problem.
To make things harder, one could even shift the position of the virtual keyboard every number of characters entered.
Of course, this doesn't solve the trojan keylogger issue at all (despite what TFA says), since the device driver would presumably enter characters into the same input buffer as a conventional keyboard would. It'd therefore arguably help against shoulder surfing in controlled installations such as ATMs, but couldn't do a thing to secure braindead joe user's passwords, with its hundreds of trojan/spyware/malware installations, because braindead joe simply doesn't have the motivation to care enough about such things to invest the necessary time to defend himself from them, and is in fact quite comfortable in his braindead state, blaming everyone
Duncan
The problem for the cracker, however, is that they'd have to have two vantage points at once, one watching the eyes, the other watching the virtual keyboard the eyes were focusing on, to get a position reference on it. Otherwise they'd have roughly the same problem as pupil tracking without the reflected spot, no reference fix. Was that movement a single letter, or to the other side of the keyboard, or somewhere in between? Just observing the eyes could certainly significantly cut down the brute force search space, thereby equally weakening the strength of the password, but it'd be anything but a one for one correspondence. (The reason the software doesn't have this problem is because it is aware of the relative position and size of the virtual keyboard onscreen.)
One could even deliberately reposition the virtual keyboard after every number of characters, as well, thus further throwing off third party eye monitors.
What TFA didn't mention, however, even tho it compared with keyloggers, is that presumably this would replace typed input as just another type of input device. As such, one may not even have to modify the keylogger to have access to the character input stream from the eye input device driver, just as it does from the keyboard device driver. A keylogger generally logs the character input stream, not the raw symbol stream, and the character input stream remains the same, no matter what device it's from or how exotic it may be. The only way around that would be a custom vertically integrated application that handles the entire stack monolithically, instead of as components tying into the conventional input stack. That'd be a huge implementation and portability headache, as it would have to be custom developed for each hardware and software combination implementation. Possible, yes, in embedded or limited hardware/software situation such as (say) ATMs, but not generally deployable without running into the conventional keylogger trojan challenges everyone else faces.
Duncan
Well, in reply to the GP, at least the GPL makes specific exception for the OS, so no, NOT everything can be regarded as derived from the OS, because it's specifically excepted.
/includes/ companies (in at least the corporate form, and AFAIK, the partnership as well, don't know about others). Thus, the only possible problem with the example above is the AFL, which I'm not familiar enough to evaluate. The GPL is fine with it and it's assumed that the company is fine with it for its own code as well. (This is why controversial semi-closed-source modules such as those from NVidia and ATI aren't issues at all for the users, only possibly for the the distributors including the creators, ATI and NVidia. As far as the GPL is concerned, a non-distributing user always has an absolute right to do whatever he wants with the code, subject of course to contrary provisions of the licenses on the other code he may be merging, but that's of no interest to the GPL, only potentially to the other license and its licensor.) In GPL terms, "distribution" within the company isn't considered distribution at all. I'm not sure how this relates to cross-subsidiary distribution, however. You'd best check that with the FSF or get the opinion of your own lawyer for that. (Borrowing from another poster's idea... "Damnit, Jim. I'm a free software user, not a lawyer.")
The same applies to the case in the parent where a company has something 20/50/30 GPL/AFL/own code. The GPL specifically excepts what one does for one's own use, and that
All that said, the last paragraph of the parent really says it all. Companies ARE used to being able to buy away, with money, any copyright issues, and this whole idea of payment in code has taken and continues to take quite some getting used to. Still, given the large and continuing to increase share of freedomware in at least the server market today, enough businesses have accepted the deal that failing to do so can put one at crippling competitive disadvantage.
While the same share hasn't reached the desktop yet, acceptance of the formerly found radical licenses of FLOSS on the server means companies have generally faced the license issue to at least some degree, and that's one less obstruction to adoption on the desktop as well. (Of course, desktop adoption has been only inching up, more outside the US than in, but with Dell's successful and expanding Linux on the desktop intro, one can hope the dam has finally broken. Regardless of whether this is the much vaunted "Year of the Linux desktop, one thing I've found for sure, riding the Free/Libre and Open Source Software wave has never been a dull ride for long, and if there's one fairly safe prediction, it's that such will continue to be the case for quite some time yet! =8^)
Duncan
Well, FLOSS programmers and businesses have issues with license proliferation, too. What happens if they want to use two libraries in their product, under two incompatible licenses?
As for code under the GPL and similar freedomware licenses, as with code under other pay-to-incorporate-into-your-product licenses, it simply comes with a license allowing you to do so under pre-set terms as long as you agree with them. If you don't, there's nothing stopping you from contacting the developers and negotiating other terms satisfactory to both parties. While pay-money-to-incorporate software developers choose to ask for money in their preset agreements, return-your-code-to-incorporate software developers ask for that instead. In both cases, if you don't like the terms, contact the developers and negotiate different terms. In both cases if you can't come to an agreement, well then, you use something else or code your own. It's that simple, and there's nothing other than the form of preset agreement separating the two types of software developers or their software.
In fact, far from business incompatible, there are a number of very successful companies using the GPL as at least one of their preset licenses. Trolltech is one such company that has chosen to incorporate BOTH types of preset license, giving developers wishing to incorporate their software a LOT of flexibility. Those who are planning to make their code free already can choose the GPL version and GPL their own code. Those who prefer to lockup their code instead of sharing it for the betterment of humankind, can choose the preset pay-money license instead of paying their code back. Great! That allows Trolltech to continue development for continued incorporation by BOTH those who release their code to the common betterment of humanity and those that prefer to lockup their code, and Trolltech is a thriving business as a result of this. Again, as with any other code shipped prelicensed, if you don't like the terms of either preset license, you are free to contact them and negotiate other terms of mutual satisfaction to both parties. Again, if such negotiation fails to produce satisfactory results, you remain as free as ever to look elsewhere or develop replacement code yourself.
So there's no problem either way. You either except the preset terms, or you contact the developers to negotiate other terms or look elsewhere. As with any other deal, if one party can't abide the terms, they simply negotiate other terms or look elsewhere. No third party left out on their own, any more than any other party who can't abide the preset terms and can't negotiate other satisfactory terms.
Duncan
From other articles I've read on this, it's both. Specifically, this is the national vote that determines how the US rep @ ISO votes. At the int'l level, each national vote has the same weight.
/would/ be able to pull it off, but as it is, it's looking really really tough for them, at least this round. I don't think anyone expected that, on either side.
Obviously, the US isn't the only nation going thru this at this time. MS has been attempting to stack the deck (typically, a working group with half a dozen or a dozen voting members, suddenly has 50 MS partners pay the couple grand to join and vote in the 6 weeks before the national vote), but perhaps surprisingly, even with that sort of stacking, they've been losing votes. Often, they do get the majority, but because this is supposed to be a consensus standard, it requires a 2/3 vote. Several nations have already voted no at the national level, while I believe two had voted yes (in the story I read), and some of those "no"s aren't yet written in stone -- as in the US, MS is playing tricks with the process, adding votes not originally in the scheduled process, etc.
Still, due to the effect of MS' money and the pull they have on their partners to stack the deck, it's really surprising they're having the trouble they are. I'm sure it is to them too, or they'd not have been so insistent on the super-expedited schedule. They are used to getting their way, buying it, skirting the law if necessary, bribing it, whatever, and it's actually surprising them that the whole world isn't simply rolling over for them any more!
The thing is, however, their effort has at least two strikes against it, in addition to the raw politics. One, ODF has already been voted in as a standard, and many of the comments are to the effect that two standards on virtually the same thing will only confuse the situation. They say MS should work to improve and update the existing standard instead, if it's so bad. Two, the MS effort is simply very poor standards material, technically. Many behaviors are defined in terms of how (proprietary) product X did it with version Y (handle wrapping like Word95 did in case Z, etc.). Defining a behavior by reference to a second behavior that itself isn't defined, simply doesn't work well in terms of a standard that everyone is supposed to be able to implement and have all versions interoperable with the standard conformant files written by other implementations. What's interesting, and must be givng MS fits, is that even after they've stacked the deck like they are doing, they're still having a tough time of it, in part because once these partners actually study the thing, enough of them decide it's bad enough they can't vote to approve it as currently speced out regardless. If MS hadn't been so insistent on expediting the process, there's a fair chance enough of these things could be worked out that MS
Unfortunately, I'm not sure what the vote at the international level must be, only that the individual nations need a 2/3 vote, and that all nations' votes count equally at the international level.
Duncan
That's very cool! =8^) Glad there's still some of that around.
You
With a bit of work and some cooperation between various entities, I've no illusions that anyone sufficiently motivated, particularly the gov or in many cases someone pretexting, could link it all together, even without the cooperation of my ISP, due to my IP appearing in various logs that link to web posts I've made, in emails and news posts, etc. Certainly, my ISP has the info to link even closer and with less effort, but this isn't so much about them, as about the Googles and others of the world that would otherwise be able to assemble a profile quite easily based on seldom changed (while my cable IP is officially dynamic, it changes maybe once a year or so if I don't change the MAC, perhaps less often than that) IP info alone. With cookies set to session-only and scripting off by default, and with privoxy setup to block or randomize (within limits) various other conceivably trackable headers (if-none-match, blocked, if-modified-since, randomized within a range, etc), IP tracking remains a rather practical way to profile me. Changing it every week or so, when I reboot for the latest linux-rc or whatever, chops up that profiling into relatively less personally revealing short segments.
Now, I DO use a relatively uncommon browser by default (Konqueror), and deliberately do NOT hide its user-agent. The IPs I get from my ISP all contain the city in the reverse lookup, and while the subnet does change within a group, if a web server operator correlates user agent with IP address, chances are they could still ID me fairly accurately, no illusions there either. However, the costs of doing so are a bit higher and the reliability rather lower, and I judge the tradeoff in publicizing the fact that not everyone's using the big four (IE/FF/Safari/Opera) worth it, thus the deliberately NOT hiding that info.
So anyway, yeah, it's a privacy thing, but I'm not fooling myself on its limits, either from the ISP, or for a sufficiently motivated server-op on a server I visit regularly, pretty much anyone else either. It does make their work harder, however, and the results a bit less reliable, which is what I'm after and all I realistically know I'm going to get, without onion routing or the like, anyway.
Duncan
No, TFA does NOT talk about blocking MACs, because that would be fscking stupid. Every time I reboot and reconnect to my ISP, I use a new MAC and therefore get a new IP (privacy... sure, the ISP can trace it, but anyone else has a bit tougher time without the ISPs cooperation), due to a little program called macchanger integrated into my bootscripts. Its site http://www.alobbs.com/macchanger says there's a similar program, SMAC, for MSWormOS. Even without that, a $5 new NIC is a new MAC.
Rather, presumably, these schools use some form of authenticated login, with school accounts. All they have to do is shut down the account and refuse to open a new one for that student (tracked after all by student ID, they change that, they lose all their credits and get to pay all sorts of new money to the school to start over), either at all (KS) or until the hefty graduated reconnect fee is paid.
Of course, there's always logging in with someone else's auth, but if they get caught doing that without permission, in most cases it'd be expulsion for cracking, and pretty much rightly so, IMO. If they have permission, then at minimum, the one lending them that permission is risking
It'll be interesting to see how this turns out, and whether they change the wording to
Duncan
And:
So, part of the training, conducted by a former Police Sgt. from the same city, is specifically how to avoid being in the way while taping. (The zoom others mention should come in handy.) There's strong emphasis on not interfering, with the training being delivered by someone that should know the situation really well. In addition, there's training on constitutional rights under the circumstances.
Since they are working closely with the police in setting this up, both the police and the citizens doing the filming should be aware of the situation, that the citizens know their rights, and that they should know how to stay out of the way. There's little doubt that both sides are aware of the national news aspect of the situation as well.
The police will likely be on their best behavior, and there'll be nothing bad to film. However, far from being a
[Begging some karma. Informative, please? =8^)]
Duncan
> The Linux kernel, for better or for worse, is going to be stuck at GPLv2.
/could/ be done, but it would be a HUGE effort, would require the general consensus agreement of nearly every one of the major contributors since the default changed to GPLv2 only, and would take some serious time. I expect it could actually be done in less than five years if required by say patent attacks or the like, but believe it's still safe to say it'd take two, minimum, and likely at least three. Five, however, should certainly be doable, PROVIDED there's consensus agreement that it's needed.
What you said previously is AFAIK correct, but this conclusion doesn't necessarily follow.
1) Until Linus changed the default kernel license to GPLv2 only, submitted code would have been GPLv2 or later by default. That's a lot of code, and it's the older code which would presumably be the most problematic in terms of tracking down authors to even discuss license changes.
2) Note the "by default" in the above. Any GPLv2 compatible licensed code can be merged, and there's a significant amount of code that's under 3-clause BSD or similar "less strict" license terms, or specifically GPLv2 or later, even if merged after the default changed.
3) Assuming an agreement between the major contributors to head toward GPLv3, and not to merge additional GPLv2 only code, a huge portion of what remains could be switched to GPLv2/v3 dual license "overnight".
4) Finally, some contributors have merged code with a "GPLv2, but I give person X (where X is generally Linus, Alan Cox, or similar well recognized major kernel contributor) the authority to make licensing decisions in my stead" type license/agreement. Obviously, if the assumption of #3 is correct, most or all of this code can equally be license switched overnight.
The above four categories would cover, wild but reasonable guess, 2/3 of the code base. Given the rate of kernel code churn, with no additional effort, only changing the default for new code to GPLv2/v3 and not accepting anything not compatible with both, within say five years, half to 2/3 (again, reasonable WAG) of the remaining code will be taken care of, simply due to code churn.
That would leave, using my for sake of argument "reasonable WAGs", ~11% of kernel code as needing further attention. Of that, it's fairly safe to assume half of the contributors will be easily found and readily agree to dual license their code GPLv2/v3.
That leaves ~5% of the current codebase as problematic. If there's anything the Bitkeeper thing demonstrated, it's how fast the kernel community can turn on a dime, code-wise, if it's in their interest and common agreement to do so. If over that same five year period, the first two years little is done besides "watchful awareness", waiting to see what areas change on their own, then years 3-4 can get increasingly focused on changing the remainder. That simple act of increasing focus is likely to half the remaining problem code again, so we're now down to perhaps 2% of the current code base for the final year's attention, with probably two releases focused almost entirely on license based code rewrite (staggered with 1-2 regular releases between them). With the code churn numbers Andrew has tracked and discussed several times since 2.6.0, 2% code base rewrite is certainly possible.
After the last GPLv2 only code has been removed, the kernel would be fully GPLv2 AND v3 compatible, and it would be legally possible to drop the GPLv2 side of the license, leaving only GPLv3 as the default for further new code, and GPLv3 compatibility fully required.
Thus, it
Linus doesn't hold copyright on all the code in the kernel, certainly, but he's certainly the pivotal consensus leader. If he doesn't think it's worth moving the kernel to GPLv3, it simply won't be done. If he DOES decide it's worth doing, THEN it's a question of whether a consensus agreement can be reached with all the other major kernel contributors as well. It's no
Mine was Qworst not ATT, but the story sounds familiar. I moved (a few blocks), they knew enough about my connection to see I had DSL and ask if I wanted it moved too, but they apparently couldn't tell the new location didn't have a drop.
/only/ three months to go until they'd be upgrading, after which I should have no problem.
/own/ service, they were under FCC monitoring on this as cooperation with the competition, so instead of taking a week to reschedule a single monkey to try again as they did with their own service, they were out THE NEXT DAY, with not one, but TWO techs, real techs not monkeys this time, and they had it straightened out in no time.
It took them several weeks, at a week to reschedule each time, to FINALLY get me even a voice line at the new location, that was SUPPOSED to be hooked up the same day I moved and my previous location was disconnected. They had all sorts of excuses, including the one week where the monkey (um, excuse me, technician) put on the ticket that the location was a vacant lot!!
So after several weeks without even a voice line, I finally got that, and started the runaround on the DSL. After another month or so of calling back every few days, I finally got the straight story. It was the same CO and DSLAM as I had had at the previous location, but due to their monkeying around, they had given the DSLAM slot to someone else, and there was a waiting list months long, but
That's when I called Speakeasy and had them sign me up. 15 days later, I was up and running, and that was after an extra day because the telco monkeys (um, technicians) robbed the reserved dry pair for the DSL and put someone's voice line on it. However, unlike their
So if I'd have called SE when I first moved, I'd have likely had DSL before the telco monkeys got their act together enough to even get me a voice line.
It's little wonder that as soon as the cableco (Cox) Internet came around, I switched from DSL and got rid of the telco's providing that, and a year later, when the cableco offered phone service, I jumped on it, and severed my last business dealings with the baboons at the telco. What was pitiful was the letters they kept sending me saying they wanted me back. Cox isn't perfect, but it's DEFINITELY been better than the collection of baboons the telco had doing things around here! (FWIW, Cox gets far better ratings than Comcast does. I read about all the stuff Comcast pulls and am glad I'm not choosing between baboons and orangutans, as it looks like I'd be doing if Comcast was the local cableco.)
Duncan
The users decide the fate of Linux... now and when Linus dies. They do so by deciding which of the Linux trees they use, if they compile it from source, or by letting their distribution choose, if they use the distribution kernel.
There's nothing saying that the Linus kernel is the only one now, and in fact, it's not. However, "mainline" has been defined by common usage to refer to the Linus or Linus blessed maintainer kernel, with other trees being lessor forks.
When Linus "retires" (he doesn't have to die, tho that would do it), as now, the choice remains with those that do the using. Even distribution kernels get used by more or fewer people, thus affecting the choice of the community as a whole.
In fact, it hasn't happened yet, so the question has yet to be resolved. However, some fairly safe predictions can be made based on what has happened with other projects, xfree86/xorg, gcc/egcs/gcc, cdtools/cdrkit, etc. Despite the fact that there are few legal restrictions preventing forking, there are very strong cohesive forces as well, and in general, the community tends to form a strong consensus agreement and for the most part, all end up going the same way, not because they have to, but because it's more efficient that way, so forks just tend to die out until there's only one dominant candidate left.
Now, Linus tends to have a generally uncommon mix of talents for a geek. He's a great coder but certainly not the greatest. However, his strength is his social consensus building skills. Very few at his technical level have that kind of social skills, and it's that, as much as anything else, that has made Linux as a kernel the dominant force it is. It would therefore be a SERIOUS loss to lose Linus, and I expect the community would be rather weaker for some time as a result, but it'd survive. A previous reply already mentioned Alan Cox. There's also Andrew Morton. At this point, I'd guess one or the other of them would take the informal (because that's what it is, even with Linus) lead, likely they'd work in tandem much as Linus and Andrew do at this point, discussion on LKML would be even more lively than usual for a few months, a few distributions or kernel trees might diverge a bit further than usual for awhile, but life would go on. Once Linus was gone and that was a fact, consensus would fairly quickly build behind a new leader.
What's a possibly more interesting question to me, is if the kernel doesn't eventually move to GPL3 (it could, but it'd take a definitive agreement from major contributors to do it, and several years, during which an increasing portion of the code would be dual-licensed GPL2/3 until the last of the GPL2 only code was removed/rewritten, so the GPL2 could be dropped), and the GNU tools do (a given), along with the OpenSolaris kernel, what might happen then, especially if the patent thing begins to force the issue on GPL2? It's possible, tho too early to predict, that GNU/OpenSolaris may become the new Linux, with Linux-the kernel eventually sidelined (/not/ dead), much like the various BSDs today. It could certainly make for an interesting few years in FLOSS-land, that's for SURE!
Duncan
The logo... Let's just say I think letters 2-4 stand out a bit much, and the first word that comes to mind is NOT fUNToo. =8^P Of course, if that's the effect you were wanting, it's certainly in the tradition of the GIMP, BitchX, C.L.I.T., etc, and I'm not one for being PC just for the sake of it. Just be aware of the word association it invokes, is all. You're probably more aware of the doors it might close than I am. If you are and it was deliberate, great. =8^)
/more/ confusing when the newbie and the trying-to-be-helper are reading two different things. (I just went thru that myself, trying to figure out which one you read. I still don't know. Good thing you weren't asking for help! =8^( )
/should/ be reading for any specific purpose, and why.
The review, from this Gentoo/~amd64 user's perspective... I'd agree with some, not all. Looking around, the biggest issue I see is that there's now two different "installer handbooks", the general Gentoo Linux handbook and the 2007.0 handbook, plus the quick install guide (and tips and tricks, and alternate install guide, and...), and it's not going to be immediately clear to a newbie if he's reading the right one or not. Then when they go looking for help, they'll likely just refer (or be referred) to "the handbook", making things all the
So after I finish this, I'm headed over to the docs list for a suggestion. For 2007.1, what about a single one-page document, listing all the installation docs with clear pointers as to what is specifically covered in each one? As some of the existing docs list several of the others, replacing the several references with a single but more prominent reference to a single list, should actually reduce total line count, I'd imagine. That should get your quick-install suggestion shown more prominently, plus provide stronger hints on exactly what one
I think that covers, directly or indirectly, most of the issues you had, including networking, the lack of stages, and the low prominence of the quickstart guide, since all three are covered, but at present it's confusing enough I can't really blame anyone for not seeing the coverage.
Anyway, as I don't believe I've had a chance to say it to you before, thanks for the distribution. For some of us, it's really almost perfect. Well, as perfect as reality gets, anyway, despite the various negatives, which from this viewpoint end up seeming rather minor when compared with the positives. Unfortunately you apparently experienced that old saw, "you can never go back", because even if you do, it's not the same. (As I'm sure you know, the events triggered some changes, but anyway, it's history now.) Still, disagree tho you might with some of his choices now that he's grown, I think you've every right to be proud of your "kid", now that he's growing into the equivalent of a young adult, as tho there have certainly been growing pains, he's turning out to be quite a responsible young member of his community. =8^)
Duncan
Keep in mind that at least where TV is ad supported, it's not necessarily the number of folks interested, but the
Ask yourself this, because you know both the ad execs and TV execs do: Given the typical geek or scientifically minded individual against the typical "OMG, Britney's got no panties!!111one!, which one is going to be EASIEST FOR THE AD BROKERS TO PROGRAM TO BUY THEIR SH*T, even tho they don't need it and it wouldn't have even occurred to them to want it without the ad, even tho they're just getting to the point of owing less on it than their only two year old car is worth, etc?
How many people that actually think for themselves have to be in the audience to make up for just ONE "programmable zombie"?
Want to know why there's so little worth watching on TV, why the reality shows and celeb news and the like seem to be the "gray goo" subliming everything in their path? Now you know. It's because the folks that watch that sort of crap are the best, the most easily programmable, ad targets in the world!
Again,
It has been nearly a decade now since I dropped TV. I found it was a natural process. I was spending more and more time on the computer, something I could actually interact with, and on the net, interacting with others, and less and less time staring at the stupid boob tube. I don't really miss it, save for the news channels when something big goes down. Sometimes I'll catch some at a friend's house or something. A few programs are acceptable, but the ads... the first time I see them might be fine, but the moment they start repeating, I often find myself driven away, to find something else to do, something less insulting to my intelligence, my ability to actually research what I buy and make up my own mind, getting the required info from sources that actually respect me as a person with my own needs and wants, not as a "consuming machine" to be programmed to buy whatever's being pushed at me the hardest.
Duncan
The usual IANAL and etc disclaimers apply... I'm simply a free software user with an interest in, and thus a bit of acquired knowledge in, this area.
/then/ attack" strategy.
Patents != trademarks != copyright.
It's not unusual for companies owning patents not to enforce them right away, and failing to do so doesn't appear to invalidate them. Cases in point are the Unisys GIF patent and the Fraunhofer/Thomson MP3 patents.
Unisys didn't enforce its GIF patent (on compression, IIRC) early in the Internet age, thus allowing it to become the early standard for limited bit-depth lossless graphics. They then attempted to enforce it after it had achieved critical mass on the Internet, with mixed success. IIRC, they attempted to collect on GIF encoding only, as decoding was apparently possible without breaking the patent. However, it was still a tax collected on GIF authoring, and as such a pain. The PNG specification was developed as a workaround, but limited/crippled support from MS in IE limited the popularity of PNG.
Similar happened with MP3 patents, with some differences (of course). MP3 dominance can in part be attributed to the fact that Fraunhofer/Thomson haven't pursued the free software based LAME encoder (among others, LAME's quality and popularity has however been a big reason for the popularity of the format), and have by stated policy declined to enforce the patent on individual users, sticking rather to enforcing the patent on proprietary/commercial (en/de)coders. The threat however has remained, and continues to be a pain for free software based MP3 support, in particular for commercial distributions such as Red Hat and Ubuntu, the reason MP3 support typically requires configuring or at least activating a "non-free" repository.
Fortunately, however, patents, unlike copyright, isn't in effect "forever", only painfully long (20 years in the US). Thus, waiting for a technology to become popular before pouncing on it and attempting to enforce patents that may apply to it has the practical effect of running out perhaps half the clock, a decade or so for the technology to become popular, leaving only a decade to attempt to collect patent royalties. The last three years will be particularly hard to collect on, as simply playing the waiting game becomes increasingly practical, so the royalty values begin to go down dramatically. That leaves a collections window of 7-12 years for anyone trying the "wait until it's standardized
The GIF patents expired in 2003 or so, so GIF is now an unencumbered technology once again. MP3 hasn't yet expired, but the clock is definitely ticking. According to Wikipedia (so good place to start but do more research if you are planning on relying on the info), the related patents expire between 2007 and 2017 in the US. However, the MP3 standard being published in 1991, with 2011 being the 20-year mark beyond that, enforcement of patents on MP3 itself extending beyond that remains in doubt, with recent legal developments likely somewhat strengthening the effect of the 2011 drop-dead date, altho that is somewhat counteracted by at least one new claimant stepping forward recently. Still, 2011 will be a very big year for MP3 technology.
Of course the MS patent claims, as with the claims of most major patent holding companies, are somewhat different, in that they are broad-based and generally subject to more of a continuing development effect. That is, it's not a single technology or a single patent in question, but a collection of patents on multiple technologies. Over the course of several years approaching a decade and longer, while some patents will expire, typically other new patents are applied for (and some granted) to replace them. Thus, the problem becomes an ongoing one, applying to anyone unwilling to continually settle for minimum 20 year-old technology.
All that said, the doctrine of laches, as mentioned by others, may still apply, tho its strength in regard to patents doesn't seem to be as high