No, he shouldn't be arrested for that. By the same token, you shouldn't be arrested either for having such a threatening tone to your posts. This holds true whether you are or or are not an FBI agent. You see, there's this funny thing called "freedom of speech". Perhaps you've heard of it? And as much as the Supreme Court has repeatedly worked to bastardize what is covered under "freedom of speech", they've repeatedly made clear that when threats are involved, it has to be of the bodily harm or death variety before it can be classified as some way as a crime and not covered under "freedom of speech". So, Barrett Brown might well be a horrible person, very little above the standards of pond scum, and a general asshole and a liar and a general attention whore whom I'd rather much like to never associate with. But as other posters note, there's lots of people like that, especially well known in the political world, and there's no real consideration that the courts should waste their time locking up every horrible asshole in the world.
Now, if you think he should be arrested because he made a threat with the intention of getting donations or indirectly to get a book deal and he doesn't actually try to follow through... But, then, you'd also have to arrest a lot of talk radio personalities who speak very big and do very little. Of course, since it's already considered okay to lie on the air and act like its news while declaring it's entertainment to the courts, we're already at a point where it's really hard to see actually where you could hold anything Barrett Brown says as a sort of fraud.
Now, if Barrett Brown actually followed through, Agent Smith could get a restraining order, and this would be a whole different matter. But, then, it wouldn't be an FBI matter.
Basically, at least as far as high tech is concerned, the patent system has morphed from its original "encourage inventors to share and explain their inventions in exchange for a short period of official monopoly" to a legally-empowered version of "I call dibs on that."
Well, no, I don't think it fair to say it "morphed" into what it is today. The patent system was created precisely to be "a legally-empowered version of 'I call dibs on that'" with the idea that by doing so, you'd "encourage inventors to share and explain their eventions" but their "call dibs on that" would be "a short period of official monopoly". To that end, the rather high-profile, high-tech boom of patenting anything and everything "on the internet" would seem to be a great boon in that it means in ~20 years we'll have a massive slew of technology of which "on the internet" won't work to grant a patent and meanwhile we'll have countless permutations of ideas all spelling out ideas.
It's the latter part of your post that really highlights the problem, that the patent office is granting patents not on actual inventions but effectively old patents with "on the internet" attached because the old patent "on the internet" is the latest trend. Hypothetically, this problem is supposed to be dealt with by having more patent clerks, but there never really was enough patent clerks ever to do a good job. I really don't know if a it's shrinking/frozen budget and the mindset that the excessive applications will be worked out in the courts that explains why the problem seems to be getting massively worse or its the complexity of the technology. I'd gather it's more the former than the latter, as it's not like there wasn't tons of patents in the 60s and 70s of a similar nature or earlier in the 20s and 30s involve "with a radio" patents, of which few were particularly novel.
Really, I don't think there's a real solution to the issue. Certainly, court cases are no fix, nor are excessive damage rewards in a loser-pay system for bogus patents; it's obviously a crippling thing for any person to really consider getting into the fray of. Meanwhile, throwing a lot of money at the patent office is unlikely to magically make the patent clerks more competent in when "on the internet" is actually novel and not simply a cheap and flimsy idea tacted on. Even the idea of requiring a demonstration to show that the inventor is "proceed[ing] to actually develop something" won't work much since it's not too hard to fake a short demo. And as much as the "skilled in the arts" test hiring software developers would seem to work, to be honest a lot of software developers are pretty arrogant. If they hear some vague idea on what a patent covers, in all but a very few cases I'd imagine they could whip up something close enough to invalidate enough of most patents to basically neuter them.
And if you're against patents in general, you might really like that last part. But the net side effect of that is more obfuscation and less "inventors [sharing]... and [explaining] their inventions" which may well suck in 20 years if people can't manage to well reverse engineer them. Of course, over all it might be no great loss. Personally, I'd be content if we just fiddling a bit more with the time range a bit. I mean, it's just lie the issue of copyright, where because of the absurd time period granted whole genres of music and entertainment have come and gone as a popular form and as such a lot of works are lost in time because there's no clear way to protect works for cultural heritage.
For patents, it's a lot less severe. But, "on the internet" patents of the early 90s are the only things that are to our bounty today. It'll only be near the end of this decade before we start seeing the beginning of a lot of serious invention in the "on the internet" space expiring. And it won't be until at least mid next decade until a lot of patented, well-designed and well engineered stuff will expire and be f
Lightning strikes and kills plenty of people every year. I guess we should just look the other way and not make a big deal when maliciousness or indifference results in electrocutions, even non-life threatening, on a large scale. No, that's obviously not true. Even if the DWH spill has no net effect, it's still a violation of a social contract. It's the same sort of contract that says electrical devices shouldn't trivially short out and give people nasty shocks. Not only that, but because such social contracts have been so frequently abused, such social contracts have been codified into law, at one level or another, to cover such things. Now, the fact that that law isn't been well enforced is news worthy on top of the shear violation of that law or the violation of social contracts.
But, yea, keep focusing on "but nature does it too". Did you know that in nature, male on male anal sex isn't entirely uncommon and that there is no real concept of rape--as consent is most often rather meaningless? Yep, think about what sort of absurd extrapolation you could get from that.
Not sure if youve ever done whole disk or volume encryption, but TrueCrypt is widely recognized as one of the best volume encryption solutions, especially for window with their WDE. Its also proprietary.
AFAIK, it's not really proprietary; it's just not "free" because it seems to be anti-commercial and put restrictions on things like forbidding obfuscating the source code.
Likewise, PGP is now (technically) proprietary, and AFAIK its still considered pretty decent (though its only a matter of time before Symantec ruins it).
Well, PGP certainly did have a reputation as being decent, as it was based upon the reputation of its creator and was specifically focused on the security of the information it encrypted. But, now that it's bought out, it sounds like you don't really trust it. Meanwhile, GPG doesn't suffer from this flaw, at least to the extent that while, yes, there might be n forks if the original community around it dissolves, it's rather likely that a few forks will be considered "good enough" based on the same point of reputation. This is, btw, why the chaos of forking usually resolves itself after a while; the "market pressure" of competing forks generally results in a few or only one really getting the focus to actually be considered the successor. That this might be "messy" is more a point that all sorts of market competition for dominance is messy.
Most strikingly, Security Essentials and Avast are both FAR superior antiviruses to ANY of the OSS AV solutions out there (moonsecure, ClamWin).
And that's probably because most OSS AV solutions focus first on protecting OSS systems which basically don't need AV because of their distribution system. AV solutions are, IMHO, a nasty hack, anyways. Since they fundamentally only work by constantly finding new viruses/malware and adding a signature to a database, it's basically a full-time job focused on every possible bad thing you could possibly do under the hope you find a counterpart malicious person and their malicious software. I'd probably have a lot more respect if this sort of fuzzing went towards fixing software. Instead, it's more like noticing that some piece of software is a sieve and creating a counterpart bit of software to put different shaped swatches of fabric in to prevent rats and roaches and whatever from coming in.
So, on the one hand, you're absolutely right. On the other hand, one could also point out that for years, in the 90s, Windows had some of the best proprietary system crash recovery software. In the OSS world, you'd just work on the point of the system not crashing and efforts to make crash recovery software would be closer to a pet project than a main consideration.
Thats true, but the beauty of a (properly functioning) competitive market is, you can just avoid the sucky vendors, and they will generally disappear.
The problem with that statement is the "properly functioning" modifier really leads your statement into "No True Scostman" territory. The simple fact is, it's a very frequent market failure that security or even just program stability takes a back seat to sufficient functionality or sufficient familiarity.
OSS tends to not have that pressure-- although of course if the project is sucky and unpopular, its unlikely to be wellknown or have any kind of community.
And OSS suffers the same issue as mentioned above, which explains why some huge projects still have massive security and stability problems. The general issue is that there's really little pressure involving the issue of security except in very isolated niches, like OpenBSD. And even there, OpenBSD's track record is really bad if you consider they basically define a crippled base install to claim any sort of real security.
Really, heres the difference youre looking at, and why I dont have this allergy to paid software. If Microsoft releases a crappy OS (bad security, or slow, or something else), there will be intense pressure on them to fix their ways; as a for-profit, publicly traded company, they very quickly run into issues if their product is unpopular.
Remind me again on just how unstable and insecure Windows was? And remind me again just how long until the Windows NT was adopted? And then further remind me how long it took before the Windows NT, the "robust" line, became actually remotely robust?
On the other hand, when a project like AmaroK makes a crappy release (bad security, or they do a 2.0), the devs can tell everyone to go get stuffed (which, in fact, they did), because there is 0 market pressure on them.
Who uses AmaroK again? I mean, I see your point to an extent, but AmaroK has virtually no "market share" to speak of in the first place so telling "everyone to go get stuffed" just doesn't mean a lot. If, on the other hand, Mozilla were to say something similar about Firefox, I'm almost certain that (a) a fork would start and (b) a good many distros would start using the fork. In fact, isn't that what happened with AmaroK, that distros switched to another media player? On the scale of whole distros, it's why there's Fedora and CentOS and Mandriva.
Obviously the very large projects like Linux do have some degree of pressure; but at the end of the day, if Linus Torvalds wants to say "Ive decided to remove memory protection", he can do so, and its really no skin off of his back. The saving grace of course is that if you have a talented community (which may not be the case), they can fork it and though painful, you can transition to the fork.
Well, that'd be sort of the point. Linus is the benevolent dictator, who helps guide inclusion of a lot of code by maintainers. Those maintainers themselves function as their own benevolent dictator upon their own section. If Linus, tomorrow, were to push something as extreme as "to remove memory protection", there's over ten people qualified to fork the Linux kernel--although due to trademarks, they'd have to call it something different. If Linus complained, it'd then be the community telling Linus to "get stuffed", since he already licensed his parts under the GPLv2 and can't rescind his code offer. So, part of what makes OSS work is the code licensing and part is how making the code tends to produce the very people capable of forking, if needed.
I have a feeling that at least SOME of the people who seem to have this allergy havent had to deal with these kind of issues, but they do happen.
The thing is, I really don't have a proprietary code allergy, per se. I certainly put
TINSSAAFL. If you try to write applications for desktop Linux, you'll find the same problem as desktop Windows: the main vendor(s) will try to subsume the need for any other vendors for any of the mainstream software. This is a natural consequence of trying to lure in more people to use the software by offering more value added. It's only really by stepping outside that into a more niche market where you have a chance of being able to write and sell applications on the desktop. On the other hand, the Mac market is quite different. It lacks the mainstream dominance and funding of Windows and it lacks the OSS, write-once-use-in-any-distro of Linux. So, there's more room for more general applications.
In the end, though, you have to first ask yourself, "if I were a potential customer, would I want to buy my application and why?" More often than not a lot of people just have no interest in your application in the first place. And the rest remaining either don't see enough value in what you offer compared to the alternatives--freeware or OSS software or even other commercial offerings--or they do see the value and do buy your software. Sure, there's more of a mindset in the Linux world of "if I can't find a free alternative now, if I wait a while I'm sure a free one will appear". But for people who have used Linux for years? We'd love to have some decent applications to feel the gaps where OSS fails, either in not producing applications at all or doing them badly.
Sure, there's a risk that it'll be a big failure to try to target the Linux community--especially if you focus on just them--, but then every such venture is a risk. It's not like most Windows developers hit it off big either, and it has nothing to do with freeware Windows software or piracy; it's just that people aren't interested in what you offer at the price you ask--and possibly not at any price. Your best bet would be to support Linux users in addition to Windows and Mac users, anyways, presuming that the added cost is reasonably low; and developing for QT should make it relatively easy, usually.
In short, I don't think you're doing yourself any favors by blaming potential customers.
I dont disagree with most of what you said, except the general implication that because some proprietary companies suck at security they all must.
Sorry, that wasn't the intended implication. The intended implication was that proprietary companies can hire competent security folk, but they have to go out of their way to budget for it, a point most proprietary companies don't focus on. Of course, the truth is that in the open source world, the "many eyes" and "statistically....a few qualified people" only works if the project receives enough attention to have those many eyes. That still leaves the outliers, both in proprietary companies and small projects, where there is enough just good programming practices to mitigate most security risks.
Also,
You see, as horrible as the whole situation might be with the potential OpenBSD's IPSEC backdoor, the fact that we know about it gives us the option to audit the code or to outright avoid the code because we know of the potential threat.
Thats true, but youll note that if the accusations are correct (and I see no indication that anyone has actually done the audit, 2 years later), it took 10 years and then the backdoor was not even caught by OSS devs, it was revealed by an insider whose NDA expired.
To the contrary, OpenBSD code audit uncovers bugs, but no evidence of backdoor covers the point that an audit was done and while bugs were found--one nasty one at that--, that there was no evidence of an extant backdoor. Of course, a more useful question would be if there ever was a backdoor, and that sort of audit wasn't done, AFAIK--and I'd really love to see someone do that audit since I know I'm not qualified. But the original discussion was the probably of a blatant backdoor surviving. And even a less blatant one apparently couldn't survive in OpenBSD it would seem--unless the backdoor was explicitly removed by the backdoor inserter at some point. Of course, without evidence of there ever being a backdoor, it's really hard to use the whole OpenBSD IPSEC Backdoor as any sort of data point.:/
Opensource systems have their share of holes, and the idea that there is a gigantic pool of people qualified to catch backdoors in something as relatively simple as a web browser-- let alone an OS-- is absurd.
It doesn't take "a gigantic pool of people qualified to catch backdoors" to fix software bugs. If it did, closed source projects would be inherently hoplessly doomed security wise. What it does take is a few or even just one qualified person to catch backdoors. For closed source, the lure of money is usually enough to hire qualified people to do the job, presuming the owner of the code cares to offer such a lure. For open source, the idea is that statistically, there's such a gigantic pool of people out there interested at all with the code that presumably a few qualified people will be in the lot and find the backdoors.
Just because you can look at the source doesnt mean you can do a remotely competent job of auditing it; and the idea that a single person could somehow audit hundreds of thousands of lines of code for security "on a whim" is even more absurd.
Not so much "on a whim", but there's been multiple security audits by researchers from different universities, often in testing automated code checkers. The same presumably happens against Windows code too, as MS offers access to source code to universities for presumably the same reason. Having said that, it's an actual known when it's done with Linux because there's no NDAs to hide any of the source or otherwise hold back the results from public scrutiny. And probably just as important, it might take a competent person to find the bug, but it often doesn't take a competent person to fix the bug--in part because often researchers spell out the fix. Yet, MS is the only one can fix their bugs--short of some potentially nasty reverse engineering--while there's a gigantic pool of people who can fix the open source bugs.
There are a lot of benefits to open source, but sometimes its advocates really stretch the imaginations with some of the claims and accusations they level against proprietary software.
Well, it's not much of an accusation to point out that Oracle and Adobe frequently learn of security vulnerabilities and seemingly sit on them for months or even years, with no reasonable possibility of anyone else offering a fix--again, short of some nasty reverse engineering. Meanwhile, as much as open source bugs have been discovered, announced, and a few times ignored, the barrier is a lot less as a point to fixing such bugs with open source--with some exceptions on the complexity of reproducing the needed build environment, at times.
You mean OpenBSD? And you notice that it's still only potential-at least, AFAIK--with no code audit so far showing any evidence of a actual backdoor? Meanwhile, in Windows world, if one of the developers on the MS IPSEC code was paid by the FBI, would MS tell us about the potential IPSEC backdoor, would MS do a code audit, would we be aware of that code audit, and would MS bother telling us everything looks okay? You see, as horrible as the whole situation might be with the potential OpenBSD's IPSEC backdoor, the fact that we know about it gives us the option to audit the code or to outright avoid the code because we know of the potential threat. Meanwhile, it's much harder to trust that a corporation, which has a vested interest in keeping as quite as possible about potential vulnerabilities as it risks their bottom line, will be open about the risk to their customers. Sometimes they try to rationalize it within the scope of "responsible disclosure". But it's only really responsible if one presumes that (a) users must use the relevant code and (b) not revealing
I'm a technically competent person (I've been coding since C64. I've built my own machines. I've installed Ubuntu via PXE.) But I don't want to spend hours and hours installing a distro, playing with it, and figuring out if it meets my needs.....only to turn around and blow it all away to try out the next one. There's too many choices and no guidance about what a particular distro does best.
Well, to me, that indicates a more fundamental issue with how distros work than anything else. As you note, distros don't generally play well together. Oh, sure, you can dual boot different distros. But, few distros default to LVM to make installing multiple distros reasonable; hell, distros can't even agree on which boot loader to use. By the same token, Xen has been around now for years, yet distros by default don't run as a Xen guest. Now, I'm sure it could be argued that most people don't install multiple distros and the LVM/Xen abstractions decrease performance. And truthfully, LVM isn't perfect (it doesn't allow on-line resizing/moving, which admittedly almost requires underlying filesystem support of which btrfs may facilitate subsuming the issue in the future) and fiddling with Xen as yet another layer of configuration isn't optimal. But LVM gives enough flexibility to be worth it. And just because the Xen guest kernel would be the default for a distro doesn't mean there couldn't be a distro host kernel also installed and set as a bootable option to be set as the default in the future once one settles on running one distro.
In short, I'd say my major complaint with distros isn't that there's too much choice. It's that no distro wants to be "just" the core, minimal system to boot other distros--including all the recovery tools you'd expect. And every other distro doesn't want to depend on that one, minimal distro because that core distro is seen as yet another target, in addition to all the others they manage, which just means more work for them. Besides, making it harder to switch forces people to stick with one distro and experiment less. I mean, if I could run Gentoo, Ubuntu, and Fedora side-by-side on a regular basis, I would have a lot less loyalty to any one of those distros and be generally more frustrated at the weaknesses of each distro when I see them.
Oh, and I'll readily admit, as much as I complain about the above, I'm quite the hypocrite. I'm certainly unwilling to invest the time and energy to make a core distro or to make sure other distro kernels work as Xen guests under it.
So basically, she did not commit and was not accused of committing any federal crime. But she may have violated a state law. And because the US DOJ and FBI did not illegally and unconstitutionally insert themselves into a state matter, it is proper to accuse them and the president of 'not wanting justice'.
Well, two points. One, the US DOJ and FBI *regularly* insert themselves into state matters, damn the constitutionality of it. Look no further than a comparison of the treatment of Sue Schmitz and Sarah Palin, based on the flimsy excuses that there might have been federal funds involved and the federal postal service might have been used--the former an interesting point because Alaska has a net funding from the federal government (ie, the state as a whole gets more federal funds than federal taxes its citizens pays in) and the latter interesting because I presume Yahoo being an out-of-state business would inherently grant interstate commerce consideration. Of course, that's the tip of the iceberg of federal involvement on a questionable basis, and both Republican and Democrat administrations have shown a willingness to interfere in state business (Terri Schiavo comes to mind), even if it's just a bully pulpit position. That leads to point two, even if the US DOJ and FBI had zero constitutionality to do anything from a legal perspective, the President of the US could certainly speak up and against seeming graft, corruption, nepotism, or whatever other bad behavior is observed, especially in a would-be VP.
On the other hand, we have someone who did violate a federal law and was properly investigated by the FBI and prosecuted by the DOJ, and that is another example of 'not serving justice'.
How many people are properly investigated by the FBI and prosecuted by the DOJ over hacking one or more email account? Again, the point isn't that the hacker did something illegal--they certainly did and it was justifiably in itself to prosecute them. It's that it's "not serving justice" when the FBI is so very selective on investigating criminals and the DOJ is very selective on enforcing the laws. It seems more about "setting an example". You can hack into thousands of email accounts or post millions of passwords, and the FBI either can't (which seems hard, but not impossible, to believe) or won't put in the effort to track and seek prosecuting those responsible successfully, except with rare exception. Now, perhaps I'm wrong and the FBI's abilities are really so woefully incapable of tracking most such breaches, either because the hackers involved are wise enough to take the necessary steps to be saved from prosecution or because the FBI simply lacks the funds/expertise over something which they'll likely take a report on but leave it as rather low priority realizing that without a good, hot lead it's not likely worth the effort--ie, it's just unlikely to lead to a successful prosecution. Or maybe the FBI really does a stellar job at investigation and the DOJ is the one who is unwilling or incapable of a successful prosecution--either for a lack of prestige or that the evidence is seen as too weak, even though it's the best detective work anyone could reasonable do. There doesn't seem to be much sign of that, though, especially when it comes to politics as a general point. Then again, that could just be that politicians are really good at covering their tracks.:/
Then again, it could be the general point that I clearly have biases. And one my main biases is the idea that most people have an agenda. And I presume the agenda of the FBI and DOJ is to seek justice of a sort but their focus tends to be on things they feel threaten the social order of things. Ie, they'll certain go out of their way to try to track criminals when there's a good bit of social unrest about the harm they're causing (the whole PSN
Good question. And I don't really have a good answer. The general issue was, Palin as Governor was supposed to engage in official government business "on the record" so that it could be archived. As I understood it, Palin had a personal e-mail account and there were allegations she was using her personal e-mail account to engage in "official government business"; the specific "government business" being potentially discussing things like Troopergate--the supposed firing of a State Trooper because of a messy divorce involving a sister. So, in essence, there was reason to believe it possible that Palin was (a) committing malfeasance of office by using it to engage in personal attacks, (b) obstructing an investigating by hiding otherwise public exchanges--which itself is indirectly another example of malfeasance of office--, and (c) clearly setting the standard that any sort of in-state investigation would be blocked or otherwise obstructed. A few steps later and recognizing that Sarah Palin, as governor, had various dealings with the federal government for things like oil pipelines and roads to nowhere, and you set the stage that an otherwise wholly internal affair might reach the scope of federal consideration of corruption--not unlike Rod Blagojevich.
Now, all of the above isn't exactly (a) any solid proof of guilt of anything or (b) providing any evidence the FBI actually had any substantial ability to do anything, anyways. The only one who seemly had the clear power and authority to investigate and see Palin potentially prosecuted and convicted was Palin. That left many people with the feeling that the FBI, if it had even some vague jurisdiction, should at least act in whatever limited capacity it could. But, then, it's pretty clear that (a) a Republican president has no interest in attacking/investigating/prosecuting a Republican vice presidential candidate as a matter of point and (b) a Democrat president has no interest in attacking/investinating/prosecuting a Republican vice presidential candidate without either overwhelimg evidence of guilt or a very serious crime being alleged--of which, I can readily imagine Democrats are just as guilty of the same sort of sloppy, intentionally so, record keeping.
Having said all that, the FBI became involved in the whole hacking incident because it was presumably done across state lines. And the actual punishment against the hacker seemed predominately about the fact that the FBI apparently: (a) talked to the hacker, (b) the hacker then tried to delete potentially incriminating evidence, and (c) the FBI promptly did a proper warrant search and found the "deleted" evidence. Yet for all that and the potential 50 years in jail, he only received a punishment of 1 year + 3 years supervised release. And AFAIK, nothing really has come from Palin's seeming abuses of office, be it a thorough investigation or anything; that's not to say it didn't happen, just that I don't recall anything more than the media vague covering the issue years later with no real mention of any police/FBI/whatever involvement.
PS - Yea, yea, sorry for going on and on about it. But it just seems rather amazing to me that the one-time hacker crime is so clear cut and results in "swift" (the hacking occurred in 2008, but the court case didn't happen until 2010) justice. Meanwhile, the potentially ongoing crime of intentionally failing to keep records results in...some political banter, some media allegations, and a general forgetfulness on almost everyone's part.
Um...the whole Sarah Palin thing was white collar, vigilante justice--over white collar, malfeasance of office. Watergate was burglary which itself is enough a crime for the police to general investigate. The same holds true for blackmail. While I'd certainly support the whole investigating of the Romney tax blackmailers and the Watergate break-in, the situation with Sarah Palin was quite different as it seemed pretty clear the FBI was, on the one hand, unwilling to launch and push on the DOJ to prosecute Palin in whatever capacity they could--which would surely expose a lot of the "dirty laundry" and influence the election--while, on the other hand, being quite willing to investigate and push on the DOJ to prosecute a person who exposed a lot of the "dirty laundry" and, hence, presumably influenced the election. I mean, at least in that instance, doesn't it seem very clear that justice was the last thing on the mind of the FBI or DOJ?
Regulation does imply a more powerful goverment. If someone runs afoul the regulation, the government steps in and hands out punitive fees, prison time or exclusion from government contracts. This amounts to actively reign into formerly autonomous business processes or personal decisions.
Really? How about this: a new branch of government called Corruption Reclamation. They can do DEA-style forfeitures of government employee (that includes the newly created branch, Supreme Court judges, the President, members of Congress, State Governors, etc, all the way down to clerical workers in some tiny 100 person town) property on the charge of corruption (meanwhile the current court system would still have criminal capacity over corruption to watch over Corruption Reclamation). You think that'd create a more powerful government? I'm pretty sure that'd lead to crippling infighting and a general inability to act. After all, isn't supposed that the basis for the three-part Federal system or the President/Congress opposite party gridlock strategy?
Except that generally, AFAIK, professors are grouped into departments which are further grouped into schools or colleges as part of the university. And at least at the department level, the professors have a lot of say on, if nothing else, complaining that (a) they all keep having to do a lot of bland stuff like teach undergraduate classes, (b) TAs, as great as they are, aren't an insignificant expense, and (c) it would be cost effective even at just the department level to fund the equivalent of a Trig or Calculus or whatever book + question/answer software, although it'd likely have to be the rate of one subject per semester eventually maturing to the point where ten or twenty subjects were covered and the only cost would be updating/maintaining those books/software. Couple that with the potential of departments of a college collaborating (the CE with education as a base, comes to mind) or departments of the same area between different universities collaborating (meaning that the top ten universities would likely share the same 100 books/software), and I'm left with the feeling it comes down the point that (a) universities have no incentive to recreate all the base material for a lot of subjects while including the risk of non-paying non-students entirely undermine a huge revenue stream (ignoring, of course, that book publishers charging $100/subject effectively does the same thing) and/or (b) that there just isn't enough direction in academia to really get anything done which makes them even more susceptible to the free rider problem.
Regardless, I think to hold the instructors blameless doesn't do the situation justice. After all, the basis for a lot of OSS is to fill an itch. Am I really lead to believe that not a single CS/CE Professor has either the itch and the skill to create the material for a 101 CS/CE subject or that plenty do but not a single one has the OSS spirit? Really, I'm more at a less on why there isn't the equivalent of OpenUniversity, OSS style already. Wikipedia doesn't remotely fit the bill. And in the end, the whole point of a university isn't so much to teach but to be accredited that one is sufficiently skilled in the arts listed on one's diploma. To that end, students do and will pay for the prestige of the university name, no matter how much free, online material there is.
If I give someone a message they can read simply by looking at it with the instruction on who to deliver the message to sitting right next to the content, I don't the content to not be read.
If I put that message in an envelope and post it in the mail, anyone but the recipient of that letter is not allowed to open it. In the USA it is a federal offense. It's illegal in pretty much every other country too.
But that's precisely the point. The expectation comes about because a law explicitly spells out a guarantee of privacy, not because envelopes offer remotely the same level of privacy protection a decent encryption scheme offers. And given that "pretty much every other country" has such standards for mail, I don't see why having such standards for internet packets is unreasonable in itself. I mean, obviously there are limits--you can't expect much privacy expectation if your plain text mail or network packets are routed through China--but the standard of expectation being in most countries makes as much if not more sense than the way copyright law is slew about the world. After all, at a pragmatic level, one really should encrypted one's mail as well and not rely upon the "expectation of privacy" and a thin, paper, easily forged envelope to offer privacy in one's plain text mail.
Data sent in plain text over a public network should not be expected to be kept private.
What is the basis for this axiom?
They can't legally do that with SSL encrypted traffic.
Unless the content is copyrighted (and in a meaningful sense, not just the de facto copyright) and decryption would be a DMCA violation, why would it be illegal to do the same with SSL traffic? Last I checked, the reason they don't do such things with SSL traffic is precisely that it's untenable to break the encryption.
It does this ONLY through network traffic analysis. Viruses/malware need to create network traffic to spread. Also many of them contact a "home" server.... No intrusion on the PC. Just looking at network packages.
Um, the GP was speaking of privacy intrusions, not PC intrusions. And it seems pretty clear that what you're doing is a privacy violation. I mean, are the rolls as equally reversed and can any other user on the network snoop on the IT department's traffic? It's by the same standard that I feel it absurd that courts have accepted pen registries or mail addresses as public information, when clearly only a private group of people can access that information.
Having said that, a company network is much different than an ISP given generally the computers are the company's, the network is the company's, and all the users are employees being paid and who have agree to abide by a policy statement noting the unilateral observation of users. To that end, it makes more logical sense that universities, ISPs, etc should be being snooped on by their users as the users are collectively the effective owners much more than the universities, ISPs, etc are the owners.
No, I'm pretty sure you're missing the big picture. Let me outline it. Apple pays a record label $0.30 to make a copy of a song. Apple then sells that copy of a song to that user for $0.30 along with a $0.70 license to make copies on multiple devices/computers. If a person wants to transfer a bought song to another person, that likely doesn't fit under the Apple license so one effectively loses that $0.70 value. Meanwhile, the $0.30 copy of a song is transferred to that other person. The only way that doesn't hold true is if Apple (1) has you sign a contract that redefines what "buy a song" means and (2) the FTC is being exceptionally lazy and allowing Apple to pull a bait and switch using the words "buy a song" outside of the understood parlance, "to buy a copy of a song", and of which even an asterisks with a footnote explanation would be unlikely to legally cover their ass.
Instead of all the unnecessary complexity of making Frankenstein code, why not just borrow an idea from the biological world? Write your malware/virus/whatever as an RNA strand that is transcribed into runnable code. Each base pair is translated, at random, to a small set of synonymous functional code. Finally, the transcoder itself (also coded in RNA) is included. The interesting bit then is, when it comes time to do a duplication, the code does reverse transcription back into RNA (a non-trivial but not impossible task) and re transcribes itself again. The real difficultly, of course, is then anti-virus/malware could simply do the reverse transcription themselves and do RNA matching. But given how trivial it would be to randomize the base -> code translation at each step...:/ The only other thing would be to try to signature match for all possible permutations of the transcoder/reverse transcoder.
I'm not convinced. It's the right choice for me. Others may disagree and want sability over recent versions.
But the problem is, again, that security patches go hand-in-hand with new version releases. Linus himself has basically stated that he doesn't feel the need to differentiate security patches vs feature patches and that almost guarantees that a person trying to backport security patches is going to miss a few security fixes, short of applying all patches (which really isn't backporting at all). And if you can't rely upon backporting on the kernel (and I say that with a lot of respect for Debian maintainers who try really hard to do so), then I'd have to say it's basically a losing cause to main stability. Now, maybe I'd feel differently if desktops actually behaved* more like servers, with a rather narrow list of applications and for which backporting could be a more relied upon method. But, I just don't see that happening.:/
*As many times as I've heard people say something like "well, they only use their desktop for web browsing and email", the simply truth I've observed is that it's always "web browsing, email, and X" where X varies between users. The net result is that a lot of extra packages that have to be maintained as well, be they music players, office software, or something else. Maybe the pool of software really is limited enough to make backporting a reasonable, long-term proposition. But, again, I really don't see that to be the case. Instead, what seems to invariably happen is that a limited amount of software is backported but most is updated as maintainers basically give up on efforts to backport on all the base software. And eventually even the base software gets a version refresh because maintainers get sick of trying to backport things like kernel 3.x security fixes on kernel 2.2.x.:)
Yep. I've been running arch for 4 years, and I've never reinstalled it.
Um, that's not much in the way of collaborating data. I mean, I was looking for something more like documentation on Arch's package system that shows it only has one style of upgrading and that you could do something silly like, say, use a 5 year old install cd and trivially update to the current release (admittedly with a probably lengthy download). I mean, AFAIK, Gentoo also follows a rolling release style of distribution, but I'm not sure if something like that is actually possible without introducing glitches.
There has been the odd problem along the way, since osme very major changes have happened. For instance, replacing/lib with a symlink to/usr/lib caused a bit of fuss, especially if you had installed custom kernels in the past (i.e. dumped files not owned by arch into a directory that the package manager thought it owned), but there were fixes on the forum.
Dare I ask how people reached the forums if/lib was broken?
don't know how Arch works as well as it does, but it does. I use it on my laptop, so random power failures aren't a problem. I think it tried so do everything as trasactionally as possible, so when things do fail part way through (e.g. due to a full disk), I've never had problems with them.
Debian (and hence Ubuntu) does that too. But, if you're in the middle of installing a new glibc + coreutils (ie, a new coreutils that requires the new glibc and an old coreutils that won't work on the new glibc) and the power goes out midway, what happens?
GlibC now has some amazingly hefty and tricky symbol versioning. I'm not sure how it works, but I've been through 4 years worth of upgrades and none of them required a re-install of everything at once. There is.so versioning too, so I think one can have an old and a new glibc without trouble.
And does Arch do that? Ie, if you install a new glibc, does the old one hang around long enough that programs that depend on it can still use it. And are programs actually compiled to work against the proper versioned.so or just against the latest.so mean an ABI break could cause issues on a failed update?
In any case, the whole "but other OSs don't do it" isn't a very compelling argument to me.
Well, it seems fundemnental to me. If you want to be up to date, you either have to updare everything at once, or keep updating everything incrementally. I honestly can't see any other options.
Sorry, I think you misunderstood what I meant. You seem to be arguing there wasn't room to complain about the former, "have to update everything at once" because other OSs require the same thing. My point was a rolling release style, like Arch supposed to offer, is and should be the proper style as a general point on a desktop OS. Of course, as you note further down, a stable version-release, supported platform makes more sense for servers.
You may find it an acquired taste. It's designed to be as simple as possible---in terms of the operating system, not the user interface. It's also got excellent, extensive documentation. This makes it much easier to bend to your will than any other system I've used. It is not, however a system for people who have no desire to read a manual.
Well, I'm perfectly find with reading a manual, personally. Having said that, if I have to read a manual every month or two just to continue to have security updates or something similar...
Once set up, it is generally trouble free. Of course things change more, but that's an inescapable facet of everything being more up to date.
Are there any operating systems out there that you don't have to do a complete upgrade to at some point? Except for Arch, of course.
If that's true of Arch, I'm very interested to hear that. Do you have any corroboration of this? I ask because my own experience with Gentoo for a long time lead me to believe you never had to do a complete upgrade. But at some point, I started having update/compile issues and when I asked, I was told I had to do a system update. And as much as that was pretty cleanly done, it did translate into the same massive d/ls that any other system upgrade entails.
The weird thing is that you level this as a criticism of Linux, except Linux is the only system available where you can, in fact, avoid ever having to do a complete upgrade at some point.
Again, if that's true about Arch, then that discounts my argument. If not entirely true, you can read a little further and see the issue is not having to upgrade per se but that a system-wide upgrade entails (a) replacing a lot of core system-wide libraries simultaneous and (b) there generally being little recovery room if something breaks/fails midway. Normally upgrades in most packaging systems involve, at most, perhaps a 30 minute stretch with potentially unrecoverable states (and even that's a messy point given the issue of power failures) during routine upgrades and because those routine upgrades only touch a small aspect of the system, usually there's enough remaining of the rest of the system to attempt a recovery. Of course, even then, if something like the latest glibc has a new bug...most distros don't allow side-by-side installs of core libraries to allow for a more graceful transition. In fact, that could be mostly dealt with with sym links, but that gets messy quickly--I know gentoo has tried fooling around with the concept but once you get into 3 or 4 libraries all compiling against different each other (and because of ABI incompatibilities there is many duplicates) it becomes a rats nest of many library installs and it still is hard to do a recovery.
In any case, the whole "but other OSs don't do it" isn't a very compelling argument to me. The fundamental points are (a) it is an issue, (b) it is fixable (admittedly not easily), and (c) I would think one or more distros would do a good job about it. If Arch is one of those distros, I'm glad to hear it and may be interested in switching to it. I just question just how robust it really is.:/
1) So, I should track kernel changes where? kernel.org? slashdot.org? And I presume I'll be doing regular recompiles then and dealing with whatever driver mess might arrive. Sounds like fun...
2) Well, web browsers sound like they'll be mostly self-correcting--Opera and Firefox tell you about updates and Chrome will auto update--but what about every other possible attack vector? I mean, the whole issue of weak ssh keys was known to me because of/. Same with the Java vulnerabilities. Well, what should I do to deal with that. Maybe I'l run a script that'll download these things--say packages--and manage them. Right, I have to build an ad-hoc package management system, even if it's just a script with a list of urls and some wget/tar/ln action. Of course, i'll have to check up on that at least once a month to make sure that doesn't break somehow and do the upkeep on that. So, overall, pretty trivial. But it's also the sort of hassle/problems which distros are there to solve.
Oh, and your dual boot suggestion is pretty hilarious. So, I should what? Setup LVM, create a duplicate system partition, do the upgrade there (still the multi-hour/day hassle), then hassle with all the config changes (and what about the fact that kde3 and kde4 may share ${HOME}/kde and their config files are incompatible)? All because zfs/btrs aren't mature enough on Linux to be mixed in with package management to do a more seemless multi-version setup? Or the fact that Linux doesn't natively support containers or zones or whatever to allow multiple distros to run simutaneously so one can be used to fix the other, if necessary?
As for your comment about Canonical failing their clientele, the problem is I've yet to see a distro that manages to not fail its clientele on precisely the issues I outlined. The best distros simply have really, really long support lines (Debian and Slackware come to mind), but they have rather terrible upgrade paths AFAIK--ie, one feels like your dual boot suggestion is a good idea which itself shows just how bad the situation is.
Oh, and as a final comment, your jab against Windows 98SE I find pretty hilarious. If anything, I feel a lot more secure running an old copy of Windows 98SE patched. Why? Because it's so ill supported as a point, about the only internet related thing I'd dare use on the thing is an up-to-date web browser and perhaps irc client. Ie, it's precisely because it's so dead that it's so readily securable. Java in Windows 98SE not updated? Don't run Java. Same with flash. Of course, I could do the same with my no-longer-supported Ubuntu. But, then, there's a reason I don't run Windows 98SE.
So some guy is saying a package manager I've never used is shit and thus all linux based systems are shit whether they have that or not? That's a lot of extrapolating there.
I've used RPM, Deb, and Portage systems. They all suffer the same fundamental issues: library upgrade issues, dependency issues, and overall system upgrades being needed at some point. Each one of those, let alone as a group, represent an aspect of frailness that leaves very little room for manual or any other sort of recovery if something goes wrong. And the robustness issue is precisely because FOSS is far from spectacular when it comes to dealing with error cases, like say a random power outage.
Hibernation is a valid point - perfect on the right hardware for years and still not working at all on some other hardware - win7 has problems there too but not as much. Older wireless hardware sucks in general but since it's no longer such a moving target (some stuff even had completely different chipsets within the same model number - you'd be hosed on any OS without the driver disk), the newer stuff is pretty well supported on all operating systems.
The hibernate issue, I would note, would have been a lousy stop gap solution, so even if it worked flawlessly, it'd solve nothing of the robustness issues. Having said that, it's pretty ridiculous that hibernation is such a massive issue given that 99% of it is a software issue (dump memory and needed drivers to disk, shutdown, reload memory and needed drivers, restart drivers, resume). Sure, there'd be all sorts of minor hiccups (like broken network connections), but the fact that hibernate fails as a more fundamental level--like when you start including encrypted swap or an encrypted hibernation file--and just fails to boot real reeks of fundamentally bad design at some level. I'm not saying the fix is trivial, but I'm not inclined to do the work more because I don't want to power cycle my computer to death in testing.
As for the wifi issue, the real problem is the driver disappearing which has happened repeatedly in the Linux world. Consider how OSS has been mostly dropped in most distros. Wifi issues is only a more poignant example because it fundamental blocks finding a resolution; other stuff, like having to use VESA to get a working accelerated graphics driver, allow one to at least progress to the point of correcting the latest disto or kernel change. Of course, it all comes down to maintainers keeping track of every change to drivers in the system and using those as a dependency trail. The only reason most distros do better with library ABI breakage is they have to do all the recompiling themselves and hence see the issues start popping up. But that can still mean a period with something broken.
The basic mistake you made, IMHO, is that you fixed something that wasn't broken. You were largely up to date.
Great point...except that in April, 10.04 LTS stops getting support--that's something I started my whole speel with precisely to outline why I did the upgrade. So, the question wasn't if I should upgrade* but when. The reason I did my upgrade now was precisely because my mom uses Ubuntu 10.04 LTS too and I wanted to do the update on my own system first to figure out what, if any, issues there might be before I upgraded her system.
*Okay, technically one shouldn't have to upgrade ever...so long as you plan to never use the internet. Meanwhile, for internet users, the Linux kernel, your web browser of choice, etc are all broken. The question isn't if those fault will be found but when, by whom, and what avenue there is for a user to avoid them. For the most part, it'd be enough, I presume, to just do out-of-package-manager, possibly-per-user upgrades for the core things, but that amounts to a good deal of personal administration I really don't want to fuss with--mostly with just having to keep on top of tracking everything that might be vulnerable and keeping up to date with keeping up to date. But if something serious comes up and involves a key component of the system, that might translate into compiling source against severely deprecated libraries in a build environment that simply doesn't exist anymore;.ie, a rather large hassle even for someone technical enough to do the work.
Slashdot Mirror
No, he shouldn't be arrested for that. By the same token, you shouldn't be arrested either for having such a threatening tone to your posts. This holds true whether you are or or are not an FBI agent. You see, there's this funny thing called "freedom of speech". Perhaps you've heard of it? And as much as the Supreme Court has repeatedly worked to bastardize what is covered under "freedom of speech", they've repeatedly made clear that when threats are involved, it has to be of the bodily harm or death variety before it can be classified as some way as a crime and not covered under "freedom of speech". So, Barrett Brown might well be a horrible person, very little above the standards of pond scum, and a general asshole and a liar and a general attention whore whom I'd rather much like to never associate with. But as other posters note, there's lots of people like that, especially well known in the political world, and there's no real consideration that the courts should waste their time locking up every horrible asshole in the world.
Now, if you think he should be arrested because he made a threat with the intention of getting donations or indirectly to get a book deal and he doesn't actually try to follow through... But, then, you'd also have to arrest a lot of talk radio personalities who speak very big and do very little. Of course, since it's already considered okay to lie on the air and act like its news while declaring it's entertainment to the courts, we're already at a point where it's really hard to see actually where you could hold anything Barrett Brown says as a sort of fraud.
Now, if Barrett Brown actually followed through, Agent Smith could get a restraining order, and this would be a whole different matter. But, then, it wouldn't be an FBI matter.
Well, no, I don't think it fair to say it "morphed" into what it is today. The patent system was created precisely to be "a legally-empowered version of 'I call dibs on that'" with the idea that by doing so, you'd "encourage inventors to share and explain their eventions" but their "call dibs on that" would be "a short period of official monopoly". To that end, the rather high-profile, high-tech boom of patenting anything and everything "on the internet" would seem to be a great boon in that it means in ~20 years we'll have a massive slew of technology of which "on the internet" won't work to grant a patent and meanwhile we'll have countless permutations of ideas all spelling out ideas.
It's the latter part of your post that really highlights the problem, that the patent office is granting patents not on actual inventions but effectively old patents with "on the internet" attached because the old patent "on the internet" is the latest trend. Hypothetically, this problem is supposed to be dealt with by having more patent clerks, but there never really was enough patent clerks ever to do a good job. I really don't know if a it's shrinking/frozen budget and the mindset that the excessive applications will be worked out in the courts that explains why the problem seems to be getting massively worse or its the complexity of the technology. I'd gather it's more the former than the latter, as it's not like there wasn't tons of patents in the 60s and 70s of a similar nature or earlier in the 20s and 30s involve "with a radio" patents, of which few were particularly novel.
Really, I don't think there's a real solution to the issue. Certainly, court cases are no fix, nor are excessive damage rewards in a loser-pay system for bogus patents; it's obviously a crippling thing for any person to really consider getting into the fray of. Meanwhile, throwing a lot of money at the patent office is unlikely to magically make the patent clerks more competent in when "on the internet" is actually novel and not simply a cheap and flimsy idea tacted on. Even the idea of requiring a demonstration to show that the inventor is "proceed[ing] to actually develop something" won't work much since it's not too hard to fake a short demo. And as much as the "skilled in the arts" test hiring software developers would seem to work, to be honest a lot of software developers are pretty arrogant. If they hear some vague idea on what a patent covers, in all but a very few cases I'd imagine they could whip up something close enough to invalidate enough of most patents to basically neuter them.
And if you're against patents in general, you might really like that last part. But the net side effect of that is more obfuscation and less "inventors [sharing] ... and [explaining] their inventions" which may well suck in 20 years if people can't manage to well reverse engineer them. Of course, over all it might be no great loss. Personally, I'd be content if we just fiddling a bit more with the time range a bit. I mean, it's just lie the issue of copyright, where because of the absurd time period granted whole genres of music and entertainment have come and gone as a popular form and as such a lot of works are lost in time because there's no clear way to protect works for cultural heritage.
For patents, it's a lot less severe. But, "on the internet" patents of the early 90s are the only things that are to our bounty today. It'll only be near the end of this decade before we start seeing the beginning of a lot of serious invention in the "on the internet" space expiring. And it won't be until at least mid next decade until a lot of patented, well-designed and well engineered stuff will expire and be f
Lightning strikes and kills plenty of people every year. I guess we should just look the other way and not make a big deal when maliciousness or indifference results in electrocutions, even non-life threatening, on a large scale. No, that's obviously not true. Even if the DWH spill has no net effect, it's still a violation of a social contract. It's the same sort of contract that says electrical devices shouldn't trivially short out and give people nasty shocks. Not only that, but because such social contracts have been so frequently abused, such social contracts have been codified into law, at one level or another, to cover such things. Now, the fact that that law isn't been well enforced is news worthy on top of the shear violation of that law or the violation of social contracts.
But, yea, keep focusing on "but nature does it too". Did you know that in nature, male on male anal sex isn't entirely uncommon and that there is no real concept of rape--as consent is most often rather meaningless? Yep, think about what sort of absurd extrapolation you could get from that.
AFAIK, it's not really proprietary; it's just not "free" because it seems to be anti-commercial and put restrictions on things like forbidding obfuscating the source code.
Well, PGP certainly did have a reputation as being decent, as it was based upon the reputation of its creator and was specifically focused on the security of the information it encrypted. But, now that it's bought out, it sounds like you don't really trust it. Meanwhile, GPG doesn't suffer from this flaw, at least to the extent that while, yes, there might be n forks if the original community around it dissolves, it's rather likely that a few forks will be considered "good enough" based on the same point of reputation. This is, btw, why the chaos of forking usually resolves itself after a while; the "market pressure" of competing forks generally results in a few or only one really getting the focus to actually be considered the successor. That this might be "messy" is more a point that all sorts of market competition for dominance is messy.
And that's probably because most OSS AV solutions focus first on protecting OSS systems which basically don't need AV because of their distribution system. AV solutions are, IMHO, a nasty hack, anyways. Since they fundamentally only work by constantly finding new viruses/malware and adding a signature to a database, it's basically a full-time job focused on every possible bad thing you could possibly do under the hope you find a counterpart malicious person and their malicious software. I'd probably have a lot more respect if this sort of fuzzing went towards fixing software. Instead, it's more like noticing that some piece of software is a sieve and creating a counterpart bit of software to put different shaped swatches of fabric in to prevent rats and roaches and whatever from coming in.
So, on the one hand, you're absolutely right. On the other hand, one could also point out that for years, in the 90s, Windows had some of the best proprietary system crash recovery software. In the OSS world, you'd just work on the point of the system not crashing and efforts to make crash recovery software would be closer to a pet project than a main consideration.
The problem with that statement is the "properly functioning" modifier really leads your statement into "No True Scostman" territory. The simple fact is, it's a very frequent market failure that security or even just program stability takes a back seat to sufficient functionality or sufficient familiarity.
And OSS suffers the same issue as mentioned above, which explains why some huge projects still have massive security and stability problems. The general issue is that there's really little pressure involving the issue of security except in very isolated niches, like OpenBSD. And even there, OpenBSD's track record is really bad if you consider they basically define a crippled base install to claim any sort of real security.
Remind me again on just how unstable and insecure Windows was? And remind me again just how long until the Windows NT was adopted? And then further remind me how long it took before the Windows NT, the "robust" line, became actually remotely robust?
Who uses AmaroK again? I mean, I see your point to an extent, but AmaroK has virtually no "market share" to speak of in the first place so telling "everyone to go get stuffed" just doesn't mean a lot. If, on the other hand, Mozilla were to say something similar about Firefox, I'm almost certain that (a) a fork would start and (b) a good many distros would start using the fork. In fact, isn't that what happened with AmaroK, that distros switched to another media player? On the scale of whole distros, it's why there's Fedora and CentOS and Mandriva.
Well, that'd be sort of the point. Linus is the benevolent dictator, who helps guide inclusion of a lot of code by maintainers. Those maintainers themselves function as their own benevolent dictator upon their own section. If Linus, tomorrow, were to push something as extreme as "to remove memory protection", there's over ten people qualified to fork the Linux kernel--although due to trademarks, they'd have to call it something different. If Linus complained, it'd then be the community telling Linus to "get stuffed", since he already licensed his parts under the GPLv2 and can't rescind his code offer. So, part of what makes OSS work is the code licensing and part is how making the code tends to produce the very people capable of forking, if needed.
The thing is, I really don't have a proprietary code allergy, per se. I certainly put
TINSSAAFL. If you try to write applications for desktop Linux, you'll find the same problem as desktop Windows: the main vendor(s) will try to subsume the need for any other vendors for any of the mainstream software. This is a natural consequence of trying to lure in more people to use the software by offering more value added. It's only really by stepping outside that into a more niche market where you have a chance of being able to write and sell applications on the desktop. On the other hand, the Mac market is quite different. It lacks the mainstream dominance and funding of Windows and it lacks the OSS, write-once-use-in-any-distro of Linux. So, there's more room for more general applications.
In the end, though, you have to first ask yourself, "if I were a potential customer, would I want to buy my application and why?" More often than not a lot of people just have no interest in your application in the first place. And the rest remaining either don't see enough value in what you offer compared to the alternatives--freeware or OSS software or even other commercial offerings--or they do see the value and do buy your software. Sure, there's more of a mindset in the Linux world of "if I can't find a free alternative now, if I wait a while I'm sure a free one will appear". But for people who have used Linux for years? We'd love to have some decent applications to feel the gaps where OSS fails, either in not producing applications at all or doing them badly.
Sure, there's a risk that it'll be a big failure to try to target the Linux community--especially if you focus on just them--, but then every such venture is a risk. It's not like most Windows developers hit it off big either, and it has nothing to do with freeware Windows software or piracy; it's just that people aren't interested in what you offer at the price you ask--and possibly not at any price. Your best bet would be to support Linux users in addition to Windows and Mac users, anyways, presuming that the added cost is reasonably low; and developing for QT should make it relatively easy, usually.
In short, I don't think you're doing yourself any favors by blaming potential customers.
Sorry, that wasn't the intended implication. The intended implication was that proprietary companies can hire competent security folk, but they have to go out of their way to budget for it, a point most proprietary companies don't focus on. Of course, the truth is that in the open source world, the "many eyes" and "statistically....a few qualified people" only works if the project receives enough attention to have those many eyes. That still leaves the outliers, both in proprietary companies and small projects, where there is enough just good programming practices to mitigate most security risks.
To the contrary, OpenBSD code audit uncovers bugs, but no evidence of backdoor covers the point that an audit was done and while bugs were found--one nasty one at that--, that there was no evidence of an extant backdoor. Of course, a more useful question would be if there ever was a backdoor, and that sort of audit wasn't done, AFAIK--and I'd really love to see someone do that audit since I know I'm not qualified. But the original discussion was the probably of a blatant backdoor surviving. And even a less blatant one apparently couldn't survive in OpenBSD it would seem--unless the backdoor was explicitly removed by the backdoor inserter at some point. Of course, without evidence of there ever being a backdoor, it's really hard to use the whole OpenBSD IPSEC Backdoor as any sort of data point. :/
It doesn't take "a gigantic pool of people qualified to catch backdoors" to fix software bugs. If it did, closed source projects would be inherently hoplessly doomed security wise. What it does take is a few or even just one qualified person to catch backdoors. For closed source, the lure of money is usually enough to hire qualified people to do the job, presuming the owner of the code cares to offer such a lure. For open source, the idea is that statistically, there's such a gigantic pool of people out there interested at all with the code that presumably a few qualified people will be in the lot and find the backdoors.
Not so much "on a whim", but there's been multiple security audits by researchers from different universities, often in testing automated code checkers. The same presumably happens against Windows code too, as MS offers access to source code to universities for presumably the same reason. Having said that, it's an actual known when it's done with Linux because there's no NDAs to hide any of the source or otherwise hold back the results from public scrutiny. And probably just as important, it might take a competent person to find the bug, but it often doesn't take a competent person to fix the bug--in part because often researchers spell out the fix. Yet, MS is the only one can fix their bugs--short of some potentially nasty reverse engineering--while there's a gigantic pool of people who can fix the open source bugs.
Well, it's not much of an accusation to point out that Oracle and Adobe frequently learn of security vulnerabilities and seemingly sit on them for months or even years, with no reasonable possibility of anyone else offering a fix--again, short of some nasty reverse engineering. Meanwhile, as much as open source bugs have been discovered, announced, and a few times ignored, the barrier is a lot less as a point to fixing such bugs with open source--with some exceptions on the complexity of reproducing the needed build environment, at times.
You mean OpenBSD? And you notice that it's still only potential-at least, AFAIK--with no code audit so far showing any evidence of a actual backdoor? Meanwhile, in Windows world, if one of the developers on the MS IPSEC code was paid by the FBI, would MS tell us about the potential IPSEC backdoor, would MS do a code audit, would we be aware of that code audit, and would MS bother telling us everything looks okay? You see, as horrible as the whole situation might be with the potential OpenBSD's IPSEC backdoor, the fact that we know about it gives us the option to audit the code or to outright avoid the code because we know of the potential threat. Meanwhile, it's much harder to trust that a corporation, which has a vested interest in keeping as quite as possible about potential vulnerabilities as it risks their bottom line, will be open about the risk to their customers. Sometimes they try to rationalize it within the scope of "responsible disclosure". But it's only really responsible if one presumes that (a) users must use the relevant code and (b) not revealing
Well, to me, that indicates a more fundamental issue with how distros work than anything else. As you note, distros don't generally play well together. Oh, sure, you can dual boot different distros. But, few distros default to LVM to make installing multiple distros reasonable; hell, distros can't even agree on which boot loader to use. By the same token, Xen has been around now for years, yet distros by default don't run as a Xen guest. Now, I'm sure it could be argued that most people don't install multiple distros and the LVM/Xen abstractions decrease performance. And truthfully, LVM isn't perfect (it doesn't allow on-line resizing/moving, which admittedly almost requires underlying filesystem support of which btrfs may facilitate subsuming the issue in the future) and fiddling with Xen as yet another layer of configuration isn't optimal. But LVM gives enough flexibility to be worth it. And just because the Xen guest kernel would be the default for a distro doesn't mean there couldn't be a distro host kernel also installed and set as a bootable option to be set as the default in the future once one settles on running one distro.
In short, I'd say my major complaint with distros isn't that there's too much choice. It's that no distro wants to be "just" the core, minimal system to boot other distros--including all the recovery tools you'd expect. And every other distro doesn't want to depend on that one, minimal distro because that core distro is seen as yet another target, in addition to all the others they manage, which just means more work for them. Besides, making it harder to switch forces people to stick with one distro and experiment less. I mean, if I could run Gentoo, Ubuntu, and Fedora side-by-side on a regular basis, I would have a lot less loyalty to any one of those distros and be generally more frustrated at the weaknesses of each distro when I see them.
Oh, and I'll readily admit, as much as I complain about the above, I'm quite the hypocrite. I'm certainly unwilling to invest the time and energy to make a core distro or to make sure other distro kernels work as Xen guests under it.
Well, two points. One, the US DOJ and FBI *regularly* insert themselves into state matters, damn the constitutionality of it. Look no further than a comparison of the treatment of Sue Schmitz and Sarah Palin, based on the flimsy excuses that there might have been federal funds involved and the federal postal service might have been used--the former an interesting point because Alaska has a net funding from the federal government (ie, the state as a whole gets more federal funds than federal taxes its citizens pays in) and the latter interesting because I presume Yahoo being an out-of-state business would inherently grant interstate commerce consideration. Of course, that's the tip of the iceberg of federal involvement on a questionable basis, and both Republican and Democrat administrations have shown a willingness to interfere in state business (Terri Schiavo comes to mind), even if it's just a bully pulpit position. That leads to point two, even if the US DOJ and FBI had zero constitutionality to do anything from a legal perspective, the President of the US could certainly speak up and against seeming graft, corruption, nepotism, or whatever other bad behavior is observed, especially in a would-be VP.
How many people are properly investigated by the FBI and prosecuted by the DOJ over hacking one or more email account? Again, the point isn't that the hacker did something illegal--they certainly did and it was justifiably in itself to prosecute them. It's that it's "not serving justice" when the FBI is so very selective on investigating criminals and the DOJ is very selective on enforcing the laws. It seems more about "setting an example". You can hack into thousands of email accounts or post millions of passwords, and the FBI either can't (which seems hard, but not impossible, to believe) or won't put in the effort to track and seek prosecuting those responsible successfully, except with rare exception. Now, perhaps I'm wrong and the FBI's abilities are really so woefully incapable of tracking most such breaches, either because the hackers involved are wise enough to take the necessary steps to be saved from prosecution or because the FBI simply lacks the funds/expertise over something which they'll likely take a report on but leave it as rather low priority realizing that without a good, hot lead it's not likely worth the effort--ie, it's just unlikely to lead to a successful prosecution. Or maybe the FBI really does a stellar job at investigation and the DOJ is the one who is unwilling or incapable of a successful prosecution--either for a lack of prestige or that the evidence is seen as too weak, even though it's the best detective work anyone could reasonable do. There doesn't seem to be much sign of that, though, especially when it comes to politics as a general point. Then again, that could just be that politicians are really good at covering their tracks. :/
Then again, it could be the general point that I clearly have biases. And one my main biases is the idea that most people have an agenda. And I presume the agenda of the FBI and DOJ is to seek justice of a sort but their focus tends to be on things they feel threaten the social order of things. Ie, they'll certain go out of their way to try to track criminals when there's a good bit of social unrest about the harm they're causing (the whole PSN
Good question. And I don't really have a good answer. The general issue was, Palin as Governor was supposed to engage in official government business "on the record" so that it could be archived. As I understood it, Palin had a personal e-mail account and there were allegations she was using her personal e-mail account to engage in "official government business"; the specific "government business" being potentially discussing things like Troopergate--the supposed firing of a State Trooper because of a messy divorce involving a sister. So, in essence, there was reason to believe it possible that Palin was (a) committing malfeasance of office by using it to engage in personal attacks, (b) obstructing an investigating by hiding otherwise public exchanges--which itself is indirectly another example of malfeasance of office--, and (c) clearly setting the standard that any sort of in-state investigation would be blocked or otherwise obstructed. A few steps later and recognizing that Sarah Palin, as governor, had various dealings with the federal government for things like oil pipelines and roads to nowhere, and you set the stage that an otherwise wholly internal affair might reach the scope of federal consideration of corruption--not unlike Rod Blagojevich.
Now, all of the above isn't exactly (a) any solid proof of guilt of anything or (b) providing any evidence the FBI actually had any substantial ability to do anything, anyways. The only one who seemly had the clear power and authority to investigate and see Palin potentially prosecuted and convicted was Palin. That left many people with the feeling that the FBI, if it had even some vague jurisdiction, should at least act in whatever limited capacity it could. But, then, it's pretty clear that (a) a Republican president has no interest in attacking/investigating/prosecuting a Republican vice presidential candidate as a matter of point and (b) a Democrat president has no interest in attacking/investinating/prosecuting a Republican vice presidential candidate without either overwhelimg evidence of guilt or a very serious crime being alleged--of which, I can readily imagine Democrats are just as guilty of the same sort of sloppy, intentionally so, record keeping.
Having said all that, the FBI became involved in the whole hacking incident because it was presumably done across state lines. And the actual punishment against the hacker seemed predominately about the fact that the FBI apparently: (a) talked to the hacker, (b) the hacker then tried to delete potentially incriminating evidence, and (c) the FBI promptly did a proper warrant search and found the "deleted" evidence. Yet for all that and the potential 50 years in jail, he only received a punishment of 1 year + 3 years supervised release. And AFAIK, nothing really has come from Palin's seeming abuses of office, be it a thorough investigation or anything; that's not to say it didn't happen, just that I don't recall anything more than the media vague covering the issue years later with no real mention of any police/FBI/whatever involvement.
PS - Yea, yea, sorry for going on and on about it. But it just seems rather amazing to me that the one-time hacker crime is so clear cut and results in "swift" (the hacking occurred in 2008, but the court case didn't happen until 2010) justice. Meanwhile, the potentially ongoing crime of intentionally failing to keep records results in...some political banter, some media allegations, and a general forgetfulness on almost everyone's part.
Um...the whole Sarah Palin thing was white collar, vigilante justice--over white collar, malfeasance of office. Watergate was burglary which itself is enough a crime for the police to general investigate. The same holds true for blackmail. While I'd certainly support the whole investigating of the Romney tax blackmailers and the Watergate break-in, the situation with Sarah Palin was quite different as it seemed pretty clear the FBI was, on the one hand, unwilling to launch and push on the DOJ to prosecute Palin in whatever capacity they could--which would surely expose a lot of the "dirty laundry" and influence the election--while, on the other hand, being quite willing to investigate and push on the DOJ to prosecute a person who exposed a lot of the "dirty laundry" and, hence, presumably influenced the election. I mean, at least in that instance, doesn't it seem very clear that justice was the last thing on the mind of the FBI or DOJ?
Really? How about this: a new branch of government called Corruption Reclamation. They can do DEA-style forfeitures of government employee (that includes the newly created branch, Supreme Court judges, the President, members of Congress, State Governors, etc, all the way down to clerical workers in some tiny 100 person town) property on the charge of corruption (meanwhile the current court system would still have criminal capacity over corruption to watch over Corruption Reclamation). You think that'd create a more powerful government? I'm pretty sure that'd lead to crippling infighting and a general inability to act. After all, isn't supposed that the basis for the three-part Federal system or the President/Congress opposite party gridlock strategy?
Except that generally, AFAIK, professors are grouped into departments which are further grouped into schools or colleges as part of the university. And at least at the department level, the professors have a lot of say on, if nothing else, complaining that (a) they all keep having to do a lot of bland stuff like teach undergraduate classes, (b) TAs, as great as they are, aren't an insignificant expense, and (c) it would be cost effective even at just the department level to fund the equivalent of a Trig or Calculus or whatever book + question/answer software, although it'd likely have to be the rate of one subject per semester eventually maturing to the point where ten or twenty subjects were covered and the only cost would be updating/maintaining those books/software. Couple that with the potential of departments of a college collaborating (the CE with education as a base, comes to mind) or departments of the same area between different universities collaborating (meaning that the top ten universities would likely share the same 100 books/software), and I'm left with the feeling it comes down the point that (a) universities have no incentive to recreate all the base material for a lot of subjects while including the risk of non-paying non-students entirely undermine a huge revenue stream (ignoring, of course, that book publishers charging $100/subject effectively does the same thing) and/or (b) that there just isn't enough direction in academia to really get anything done which makes them even more susceptible to the free rider problem.
Regardless, I think to hold the instructors blameless doesn't do the situation justice. After all, the basis for a lot of OSS is to fill an itch. Am I really lead to believe that not a single CS/CE Professor has either the itch and the skill to create the material for a 101 CS/CE subject or that plenty do but not a single one has the OSS spirit? Really, I'm more at a less on why there isn't the equivalent of OpenUniversity, OSS style already. Wikipedia doesn't remotely fit the bill. And in the end, the whole point of a university isn't so much to teach but to be accredited that one is sufficiently skilled in the arts listed on one's diploma. To that end, students do and will pay for the prestige of the university name, no matter how much free, online material there is.
But that's precisely the point. The expectation comes about because a law explicitly spells out a guarantee of privacy, not because envelopes offer remotely the same level of privacy protection a decent encryption scheme offers. And given that "pretty much every other country" has such standards for mail, I don't see why having such standards for internet packets is unreasonable in itself. I mean, obviously there are limits--you can't expect much privacy expectation if your plain text mail or network packets are routed through China--but the standard of expectation being in most countries makes as much if not more sense than the way copyright law is slew about the world. After all, at a pragmatic level, one really should encrypted one's mail as well and not rely upon the "expectation of privacy" and a thin, paper, easily forged envelope to offer privacy in one's plain text mail.
What is the basis for this axiom?
Unless the content is copyrighted (and in a meaningful sense, not just the de facto copyright) and decryption would be a DMCA violation, why would it be illegal to do the same with SSL traffic? Last I checked, the reason they don't do such things with SSL traffic is precisely that it's untenable to break the encryption.
Um, the GP was speaking of privacy intrusions, not PC intrusions. And it seems pretty clear that what you're doing is a privacy violation. I mean, are the rolls as equally reversed and can any other user on the network snoop on the IT department's traffic? It's by the same standard that I feel it absurd that courts have accepted pen registries or mail addresses as public information, when clearly only a private group of people can access that information.
Having said that, a company network is much different than an ISP given generally the computers are the company's, the network is the company's, and all the users are employees being paid and who have agree to abide by a policy statement noting the unilateral observation of users. To that end, it makes more logical sense that universities, ISPs, etc should be being snooped on by their users as the users are collectively the effective owners much more than the universities, ISPs, etc are the owners.
No, I'm pretty sure you're missing the big picture. Let me outline it. Apple pays a record label $0.30 to make a copy of a song. Apple then sells that copy of a song to that user for $0.30 along with a $0.70 license to make copies on multiple devices/computers. If a person wants to transfer a bought song to another person, that likely doesn't fit under the Apple license so one effectively loses that $0.70 value. Meanwhile, the $0.30 copy of a song is transferred to that other person. The only way that doesn't hold true is if Apple (1) has you sign a contract that redefines what "buy a song" means and (2) the FTC is being exceptionally lazy and allowing Apple to pull a bait and switch using the words "buy a song" outside of the understood parlance, "to buy a copy of a song", and of which even an asterisks with a footnote explanation would be unlikely to legally cover their ass.
Instead of all the unnecessary complexity of making Frankenstein code, why not just borrow an idea from the biological world? Write your malware/virus/whatever as an RNA strand that is transcribed into runnable code. Each base pair is translated, at random, to a small set of synonymous functional code. Finally, the transcoder itself (also coded in RNA) is included. The interesting bit then is, when it comes time to do a duplication, the code does reverse transcription back into RNA (a non-trivial but not impossible task) and re transcribes itself again. The real difficultly, of course, is then anti-virus/malware could simply do the reverse transcription themselves and do RNA matching. But given how trivial it would be to randomize the base -> code translation at each step... :/ The only other thing would be to try to signature match for all possible permutations of the transcoder/reverse transcoder.
But the problem is, again, that security patches go hand-in-hand with new version releases. Linus himself has basically stated that he doesn't feel the need to differentiate security patches vs feature patches and that almost guarantees that a person trying to backport security patches is going to miss a few security fixes, short of applying all patches (which really isn't backporting at all). And if you can't rely upon backporting on the kernel (and I say that with a lot of respect for Debian maintainers who try really hard to do so), then I'd have to say it's basically a losing cause to main stability. Now, maybe I'd feel differently if desktops actually behaved* more like servers, with a rather narrow list of applications and for which backporting could be a more relied upon method. But, I just don't see that happening. :/
*As many times as I've heard people say something like "well, they only use their desktop for web browsing and email", the simply truth I've observed is that it's always "web browsing, email, and X" where X varies between users. The net result is that a lot of extra packages that have to be maintained as well, be they music players, office software, or something else. Maybe the pool of software really is limited enough to make backporting a reasonable, long-term proposition. But, again, I really don't see that to be the case. Instead, what seems to invariably happen is that a limited amount of software is backported but most is updated as maintainers basically give up on efforts to backport on all the base software. And eventually even the base software gets a version refresh because maintainers get sick of trying to backport things like kernel 3.x security fixes on kernel 2.2.x. :)
Um, that's not much in the way of collaborating data. I mean, I was looking for something more like documentation on Arch's package system that shows it only has one style of upgrading and that you could do something silly like, say, use a 5 year old install cd and trivially update to the current release (admittedly with a probably lengthy download). I mean, AFAIK, Gentoo also follows a rolling release style of distribution, but I'm not sure if something like that is actually possible without introducing glitches.
Dare I ask how people reached the forums if /lib was broken?
Debian (and hence Ubuntu) does that too. But, if you're in the middle of installing a new glibc + coreutils (ie, a new coreutils that requires the new glibc and an old coreutils that won't work on the new glibc) and the power goes out midway, what happens?
And does Arch do that? Ie, if you install a new glibc, does the old one hang around long enough that programs that depend on it can still use it. And are programs actually compiled to work against the proper versioned .so or just against the latest .so mean an ABI break could cause issues on a failed update?
Sorry, I think you misunderstood what I meant. You seem to be arguing there wasn't room to complain about the former, "have to update everything at once" because other OSs require the same thing. My point was a rolling release style, like Arch supposed to offer, is and should be the proper style as a general point on a desktop OS. Of course, as you note further down, a stable version-release, supported platform makes more sense for servers.
Well, I'm perfectly find with reading a manual, personally. Having said that, if I have to read a manual every month or two just to continue to have security updates or something similar...
If that's true of Arch, I'm very interested to hear that. Do you have any corroboration of this? I ask because my own experience with Gentoo for a long time lead me to believe you never had to do a complete upgrade. But at some point, I started having update/compile issues and when I asked, I was told I had to do a system update. And as much as that was pretty cleanly done, it did translate into the same massive d/ls that any other system upgrade entails.
Again, if that's true about Arch, then that discounts my argument. If not entirely true, you can read a little further and see the issue is not having to upgrade per se but that a system-wide upgrade entails (a) replacing a lot of core system-wide libraries simultaneous and (b) there generally being little recovery room if something breaks/fails midway. Normally upgrades in most packaging systems involve, at most, perhaps a 30 minute stretch with potentially unrecoverable states (and even that's a messy point given the issue of power failures) during routine upgrades and because those routine upgrades only touch a small aspect of the system, usually there's enough remaining of the rest of the system to attempt a recovery. Of course, even then, if something like the latest glibc has a new bug...most distros don't allow side-by-side installs of core libraries to allow for a more graceful transition. In fact, that could be mostly dealt with with sym links, but that gets messy quickly--I know gentoo has tried fooling around with the concept but once you get into 3 or 4 libraries all compiling against different each other (and because of ABI incompatibilities there is many duplicates) it becomes a rats nest of many library installs and it still is hard to do a recovery.
In any case, the whole "but other OSs don't do it" isn't a very compelling argument to me. The fundamental points are (a) it is an issue, (b) it is fixable (admittedly not easily), and (c) I would think one or more distros would do a good job about it. If Arch is one of those distros, I'm glad to hear it and may be interested in switching to it. I just question just how robust it really is. :/
And let me disambiguate:
1) So, I should track kernel changes where? kernel.org? slashdot.org? And I presume I'll be doing regular recompiles then and dealing with whatever driver mess might arrive. Sounds like fun...
2) Well, web browsers sound like they'll be mostly self-correcting--Opera and Firefox tell you about updates and Chrome will auto update--but what about every other possible attack vector? I mean, the whole issue of weak ssh keys was known to me because of /. Same with the Java vulnerabilities. Well, what should I do to deal with that. Maybe I'l run a script that'll download these things--say packages--and manage them. Right, I have to build an ad-hoc package management system, even if it's just a script with a list of urls and some wget/tar/ln action. Of course, i'll have to check up on that at least once a month to make sure that doesn't break somehow and do the upkeep on that. So, overall, pretty trivial. But it's also the sort of hassle/problems which distros are there to solve.
Oh, and your dual boot suggestion is pretty hilarious. So, I should what? Setup LVM, create a duplicate system partition, do the upgrade there (still the multi-hour/day hassle), then hassle with all the config changes (and what about the fact that kde3 and kde4 may share ${HOME}/kde and their config files are incompatible)? All because zfs/btrs aren't mature enough on Linux to be mixed in with package management to do a more seemless multi-version setup? Or the fact that Linux doesn't natively support containers or zones or whatever to allow multiple distros to run simutaneously so one can be used to fix the other, if necessary?
As for your comment about Canonical failing their clientele, the problem is I've yet to see a distro that manages to not fail its clientele on precisely the issues I outlined. The best distros simply have really, really long support lines (Debian and Slackware come to mind), but they have rather terrible upgrade paths AFAIK--ie, one feels like your dual boot suggestion is a good idea which itself shows just how bad the situation is.
Oh, and as a final comment, your jab against Windows 98SE I find pretty hilarious. If anything, I feel a lot more secure running an old copy of Windows 98SE patched. Why? Because it's so ill supported as a point, about the only internet related thing I'd dare use on the thing is an up-to-date web browser and perhaps irc client. Ie, it's precisely because it's so dead that it's so readily securable. Java in Windows 98SE not updated? Don't run Java. Same with flash. Of course, I could do the same with my no-longer-supported Ubuntu. But, then, there's a reason I don't run Windows 98SE.
I've used RPM, Deb, and Portage systems. They all suffer the same fundamental issues: library upgrade issues, dependency issues, and overall system upgrades being needed at some point. Each one of those, let alone as a group, represent an aspect of frailness that leaves very little room for manual or any other sort of recovery if something goes wrong. And the robustness issue is precisely because FOSS is far from spectacular when it comes to dealing with error cases, like say a random power outage.
The hibernate issue, I would note, would have been a lousy stop gap solution, so even if it worked flawlessly, it'd solve nothing of the robustness issues. Having said that, it's pretty ridiculous that hibernation is such a massive issue given that 99% of it is a software issue (dump memory and needed drivers to disk, shutdown, reload memory and needed drivers, restart drivers, resume). Sure, there'd be all sorts of minor hiccups (like broken network connections), but the fact that hibernate fails as a more fundamental level--like when you start including encrypted swap or an encrypted hibernation file--and just fails to boot real reeks of fundamentally bad design at some level. I'm not saying the fix is trivial, but I'm not inclined to do the work more because I don't want to power cycle my computer to death in testing.
As for the wifi issue, the real problem is the driver disappearing which has happened repeatedly in the Linux world. Consider how OSS has been mostly dropped in most distros. Wifi issues is only a more poignant example because it fundamental blocks finding a resolution; other stuff, like having to use VESA to get a working accelerated graphics driver, allow one to at least progress to the point of correcting the latest disto or kernel change. Of course, it all comes down to maintainers keeping track of every change to drivers in the system and using those as a dependency trail. The only reason most distros do better with library ABI breakage is they have to do all the recompiling themselves and hence see the issues start popping up. But that can still mean a period with something broken.
Great point...except that in April, 10.04 LTS stops getting support--that's something I started my whole speel with precisely to outline why I did the upgrade. So, the question wasn't if I should upgrade* but when. The reason I did my upgrade now was precisely because my mom uses Ubuntu 10.04 LTS too and I wanted to do the update on my own system first to figure out what, if any, issues there might be before I upgraded her system.
*Okay, technically one shouldn't have to upgrade ever...so long as you plan to never use the internet. Meanwhile, for internet users, the Linux kernel, your web browser of choice, etc are all broken. The question isn't if those fault will be found but when, by whom, and what avenue there is for a user to avoid them. For the most part, it'd be enough, I presume, to just do out-of-package-manager, possibly-per-user upgrades for the core things, but that amounts to a good deal of personal administration I really don't want to fuss with--mostly with just having to keep on top of tracking everything that might be vulnerable and keeping up to date with keeping up to date. But if something serious comes up and involves a key component of the system, that might translate into compiling source against severely deprecated libraries in a build environment that simply doesn't exist anymore;.ie, a rather large hassle even for someone technical enough to do the work.