Creating custom software will always be a good business plan, and it actually gets better rather than worse as more applications become subsumed by FOSS.
Instead of trying to sell software products, which basically just treats compiled code like manufactured widgets and developers like skilled factory workers, you sell your labor.
I think that in the very long run, while there will always be some market for widget-like commercial software, it will be dwarfed by the "service sector" software industry (if it's not already) which will employ far more programmers.
This will only work if the development team can add enough compelling features to the closed-source version to prevent users from just passing it by on their way to the free version. (If it was trivial, more companies would try the open-then-closed-source maneuver.) And if they could start doing that tomorrow, they'd probably be doing a lot better at their current plan, producing closed-source add ons that enhance the FOSS platform.
The fact that they can't make the current business plan work suggests to me that either the free version meets the needs of most users, or that they're just not very good at enhancing the base version in ways that gets people to open their wallets. Neither bodes very well for them.
Offering a commercial alternative to a free software product isn't an easy or safe plan -- commercial XWindows servers have existed for years, but how many people do you know running them? -- if the free package is good enough.
Ultimately, the key is producing features that users are willing to pay for, and selling them for a price they want to pay. If you can do that, you can survive whether your business model revolves around an open-source or closed-source core; if you can't, neither will help in the long run.
That sounds like willful ignorance to me, at least if it's taken to an extreme. It's fairly easy to do some research and figure out what your colo's policies are, and whether they actually enforce those policies. If they don't, chances are they might not be a good place to house your server, because their attitude could come back to bite them eventually.
It's not necessary to know exactly what everyone else sharing a colo facility with you is up to, but you should at least have some measure of confidence in the colo operator to keep things above-board enough to keep the whole thing from getting shut down. If they allow illegal or generally-despised activities to go on, and develop a reputation for that sort of thing, they're risking everyone who's using the facility.
It's like renting an apartment where the landlord turns a blind eye to the meth lab downstairs; there's a limit to how far you want to take 'minding your own business.'
Using dollars is not a good metric. Food production is heavily subsidized; the price you pay for food at the grocery store in no way represents its actual costs to produce. (And it gets even worse when you try to take into account the externalities of food production that are allowed to be placed on the public without recompense -- the runoff from farms into water supplies and the Gulf, for one example.)
A better way is to look at energy and calories. The exact values depend on the food, your location, and other factors, but it's not atypical for 1 calorie of food energy to use over 100 calories of petroleum energy in its creation, transportation, packaging, and retail sale. If you buy nothing but raw foods at farmers' markets, the number will of course be lower, but even something as innocent as iceberg lettuce can have a huge energy debt. Michael Pollan does an analysis in one of his books, and if you are on the East Coast, eating lettuce from California, it's something like 4500 cal of petroleum for the measly 80 cal of human-consumable energy in the lettuce. It's much worse for heavily-processed foods.
I am a big proponent of bicycling, but it's not necessarily as obvious a win on carbon-emission grounds as it might appear. There are lots of other good reasons to bike, though. (To name a few, it decreases urban air pollution, which leads to health problems that consume resources, same also with obesity-related issues, if widely adopted it would make the roads safer, etc.)
I think of it as a "healthy / pleasant lifestyle" choice, rather than an "environmental" choice. You cannot claim to be much of an environmentalist while leading a resource-intensive, Western lifestyle. It simply cannot be done. Even the most "environmentally conscious," bike-riding, CFL-using, Prius-owning, self-righteous neo-hippies are contributing massively to the problem, practically just by getting up in the morning. You cannot eat, drink, shit, or die in America and not be contributing to the problem in some way. (You can't really even kill yourself without incurring a debt, since the way we deal with dead bodies is, in itself, not exactly environmentally sound. Although that's probably the most un-hypocritical approach.)
The truth is that individual choices matter very little in the grand scheme. If you drive an efficient vehicle, or ride a bike, great -- that's slightly less demand for gasoline, slightly lower prices, and slightly more gas for someone else to put in their Hummer (or someone in India to fuel their shiny new Tata). It's still getting pumped out of the ground as fast as we can find it either way. Our civilization is going to hurtle down the road it's going down, until it runs into something Really Bad -- maybe global warming, maybe Peak Oil, maybe something else -- and either engineers a clever way around it, or collapses in an orgy of suffering and death like nothing history has ever recorded. Whether or not you rode a bike to work won't change the outcome in the slightest.
It might make you feel a lot better, though, in the meantime. That's why I do it, and why I'd tell anyone they should as well.
You're taking on premise that Novell does more good than harm to the Linux / Free Software world. I suspect that the Boycott Novell people would disagree with that.
I haven't been firmly convinced either way, but their stance seems to be that Novell is basically Microsoft's sleeper agent, and that the OSS world would be better off if they just disappeared tomorrow, even though that would mean some of the less-evil things they're doing would stop, than if they continue. I.e., they think the continued existence of Novell, taken as a whole in its current form, is a bad thing.
I don't think either camp -- pro-Novell or anti-Novell -- is really doing a great job of making its points in a rational and unemotional way. There seems to be a lot of noise and argument but not a lot of actual substantiative discussion.
The car that ran into you took most of the damage because of the crumple zones in the front -- this is by design. Her car acted exactly as it was supposed to in a rear-end scenario.
I've often wondered this also...a few years ago there were reports that IBM was going to do it, and they had an "IBM Desktop Linux" distro waiting in the wings... and then, nothing. Or basically nothing, what showed up was a modified version of RHEL, I think. It was anticlimactic, to say the least.
The only thing I can come up with is they're still burning from the OS/2 debacle and have an aversion to doing anything that smells like a consumer or desktop operating system. As an organization, I get the feeling they've sworn off that particular segment of the market and put it in the "never again" file.
That doesn't explain why they don't offer a server Linux tailored specifically for their hardware -- maybe just fears that it would cannibalize OS/400 (or whatever they're calling it this week) and z/OS sales? That seems logical, if shortsighted.
A few years ago it would have been massive, but even today I think it would still be significant validation for Linux if IBM actually released a distro themselves. Since a fair bit of their low-end and midrange strategy is focused on Linux, and they have a wide variety of (profitable!) software that runs on Linux, and the near-triviality of assembling a distro, plus the support revenue they'd be able to steal from RedHat or SuSE (that basically every Linux-on-IBM client is paying)... it seems like a no-brainer to me.
Maybe they're biding their time, but more likely I think it's just the schizophrenia endemic to many large organizations, where there's just nobody in the right place with the right power to do what obviously needs to be done, so everybody instead goes their separate ways.
In a lot of ways I think Linux in general -- at least, "Desktop Linux" -- is held back by the same mode of thinking. There are a lot of people trying to copy Microsoft, and that just isn't going to work. You can't out-Windows Windows, (or Office). You can try, and you can perhaps even get very close, but you're inherently setting yourself up for failure: the "real thing" will always be what's being emulated, and users will pick up on that and realize they're getting something that's inherently second-rate.
The areas where Linux really leads are mostly in areas where, as a platform and in general, it doesn't try to blindly emulate Microsoft behavior, and does what's really best.
In my experience anyway, the attractiveness of 'clone' applications is overestimated by developers; users are generally quite willing to learn something new, be it an application or a workflow/process, if the new thing is obviously superior in a meaningful way ("meaningful" as in "makes their job easier"). People do this all the time; when you run into resistance is when there's relearning for no obvious gain (e.g. Office 2007).
The last time I heard about anyone getting disconnected for running a server, even anecdotally, was back in the mid-90s. This was also when the local cable internet provider was threatening to disconnect anyone who had multiple computers sharing the same connection using DNSMasq. (They wanted you to rent multiple modems and pay for essentially separate lines of service for each computer in your house.) And even then, the only person I ever heard of who actually got disconnected was pretty egregious: trying to cash in on the dot-com boom running a domain-squatting porn operation from his house.
In general, nobody really gave a crap about either restriction -- servers or DNS masquerading -- then, and nobody cares now; the only reason why I suspect they've left the bit about "no servers" in the TOS is because the providers don't want to deal with support issues, and it's an easy way to push home-office customers up to the high-priced "Business" tiers. I have never seen or experienced any effort at trying to enforce it, and even the dumbest ISPs -- at least those I've ever had -- seem to realize that ham-fistedly blocking all incoming connections would break a wide variety of applications.
And on the whole, I don't think most ISPs really care. Most home users aren't going to spring for a Business-class connection no matter what, so it's squeezing blood from a stone in any case, and so long as a few geeks running servers doesn't result in a lot of support calls or harm the network, they seem content to ignore it.
Unless you are looking at a fairly strange cross-section of consumer routers, most of them do not run Linux. Only a handful of the ones offered by Linksys, D-Link, etc. do. The majority run VxWorks, I believe.
A few years back there were actually more Linux-based routers but as cost pressures and competition have increased the manufacturers seem to have moved away in order to reduce the parts count. Broadband routers are the only pieces of equipment I've seen where the hardware specs have actually fallen, year over year, for comparable pieces of gear.
Anyway, if you do happen to get a real Linux router (like the Linksys WRT54GL, or early *G editions) and reflash the firmware to DD-WRT, you can enable IPv6. I don't think it does automatic 6to4 (at least it doesn't in the version I'm running) so it's not quite as slick as the Apple routers, but the capability is definitely there if you're running a decent load of software. I don't know if the capability is actually been removed from the kernel in stock firmwares or just not enabled.
I don't know what VxWorks' support for v6 is like, so I'm not sure how trivial it is for manufacturers to enable it, if they wanted to.
I think it should be pointed out that the definition isn't that simple. Here's a table (PDF) of how the U.S. Government defines a "small business." It varies by sector and sub-sector (a 'small' peanut farm is defined differently from a 'small' aerospace parts manufacturer, since the latter is significantly more capital intensive than the former).
Most IT-related activities are at the higher end of the spectrum (see p.30 in the PDF) which tops out at $25 million/year ("services") or 150 employees ("value added reseller"), but there are some odd special cases in there. "Technical consulting," for instance, is $7M, and "Engineering services" is only $4.5M, but "Custom Computer Programming Services" is $25M. Makes you wonder who that was gerrymandered for...
Nuclear submarines aren't necessarily perfect. I'm not sure how good the Soviets ever got at tracking ours, but it's not inconceivable that if that was the only threat, a country could get pretty creative in tracking them, and come up with some sort of first strike to take them all out at once. Maybe with some type of undersea listening network like the U.S. had (has?) in the Atlantic.
The thinking behind the nuclear "trident" of bombers, ICBMs, and submarines -- aside from keeping all three branches of the U.S. military (and the contractors that support them) happy, which is probably a large part -- is that it keeps your enemy from concentrating their energies behind a single defensive strategy. If you have all three, then your enemy would have to build a SAM and early-warning system to shoot down the bombers, anti-missile technology to intercept the ICBMs, and ASW systems to go after the submarines. It's not practical. But if you only had one, they'd be able to focus their efforts and might be able to produce a viable defense.
When ever you try to assign gender on anything except the Chromosomes it will fail.
Actually it fails pretty spectacularly when you try to determine it based on chromosomes, too. There are XY women with androgen insensitivity syndrome (AIS), and both XXY and XYY men. In many cases, especially those of AIS, they may go their whole lives without knowing that their chromosomes convey something different than their sex organs.
And using sex organs starts to fail as well when you get into intersexed and transgendered people; someone's sex organs may not match the gender they 'pass' as in social contexts, or that they prefer to be treated as.
Persistent internet connectivity is definitely one of those things I never thought I'd find useful, but now that I have it in the form of a smartphone, I'm never going back. Like from-my-cold-dead-hands never.
First, being able to send and receive email anywhere is neat. This may not be quite as impressive to people who've been on unlimited-SMS plans for a while, but I never got into text messaging. Push email on the other hand has definitely changed how I work. (And does seem like a potential source of work/life imbalance; I keep the push feature turned off after hours.)
Services like Google Maps are suddenly a lot more useful when used from a GPS-enabled smartphone than I'd ever realized they were before (and I'd been a big fan of them on my computer, too). It's done to walking around what having a navigation unit did to driving; I can basically go out and not really be terribly worried about getting somewhere, or looking up a store's hours, or finding the nearest [whatever] near [someplace]. It is worth getting a smartphone with GPS for this purpose alone, IMO.
Being able to do a quick Google search anywhere, pretty much at the drop of a hat, is also nice. I think it's one of those things that will pretty quickly become second-nature to a lot of people; even the people who don't actually have phones that can do it themselves, quickly learn that other people do and expect the ability to be there. Wikipedia is a little ugly on my phone at least, but it's handy to have access to as well.
My bank, Amtrak, and Delta Airlines all have mobile sites up and running now, and it seems to becoming more common daily. It is really nice to be able to look and see, as soon as you hit the tarmac, whether your connecting flight is still on-time or been delayed (meaning: do you need to haul ass off the plane, or can you wait and let everyone else get off first?).
There's also software that lets you use a 802.11-capable handset (at least Symbian ones) as an access point, which is great if you want an alternative to finicky Bluetooth or USB tethering, or you want to share your cell data connection with a group of people in a remote location. That's saved me a lot of headaches. (Software is JoikuSpot, I'm a big fan.)
I can see how nothing that a smartphone does is really impossible to do with a small laptop and free wireless connections -- and that was the route I took, for several years -- but there's really very little comparison. I don't carry my laptop around nearly as much since getting the smartphone, and I haven't felt like the money for the data service was anything but a great deal since getting it, either.
That would be one solution, and a good one at that, but it's non-trivial. The hardware players have their keys stored in secure memory and I'm not sure what it would take to extract -- maybe you could do it in a good university lab somewhere.
So far I think there has only been success in extracting the keys used by software players, which can be disabled in later disc pressings. (The GP's description of how key distribution and encryption works is a little simplified from reality; there's a truly bizarre revocation scheme shoehorned in there that's quite complex.)
In fact I think that the granularity of player keys is significantly higher than just one key per model of player. It may go down to the level of individual players, akin to serial numbers, although I'm not entirely sure there.
I'm failing to see why people would find this so objectionable...
Perhaps because it's a blatantly obvious cash-grab by an organization whose ostensible purpose is to serve the Internet community, but instead lives off of it parasitically?
Perhaps because it would require many people to register multiple domain names (possibly thousands) in order to protect their brands, or else leave them open to be registered by squatters and phishers.
Perhaps because there's just no legitimate technical reason for it?
Perhaps because it would be a giant pain in the ass and probably break various pieces of software, requiring people who have no interest in the issue either way to expend energy on it?
Those are just the things that come immediately to mind.
I mean, if I can't use my Gmail address to logon to websites that actually support OpenID, then why would I bother?
Yep, that's my question too. I was excited for a minute, thinking that I'd be able to suddenly use my Gmail/Google ID to sign into various OpenID-enabled sites... but then they went and fucked it up.
They might as well have not bothered. The whole point of OpenID is interoperability. If they don't want to play along with the consensus, they shouldn't bother trying.
I'd really hope that whoever owns the OpenID trademark comes after them and forces them to stop calling whatever they're doing "OpenID". If it's not compatible with an existing specification, it's not OpenID. They will risk seriously devaluing their trademark if they allow incompatible implementations to use the name. They need to be ruthless about this. Google can do whatever it wants and call it "GoogleID", but if it's called "OpenID", it needs to be compatible with everyone else claiming to be that.
"Temporarily" means that time was wasted. People had to re-discover something that was previously known. That, optimally, should never happen.
That someone had to re-discover something means that the original discovery was forgotten; that's what we'd all (I hope) like to avoid. Time spent rediscovering things that were already known in the past is time that can't be spent actually making new progress; society suffers if we have a spotty collective memory.
1. This is *not* Free Software. You are correct in thinking that Free Software is fundamentally incompatible with (software) DRM. There's just no way to make it work. The user freedom that's part of the very definition of what constitutes Free Software means that anyone with half a brain could reverse-engineer the DRM implementation, extract the key, and generally have their way with the content. This isn't a bug, it's a feature.
2. This is only "open source" in the most minimal, literal sense. Basically, if you sign some sort of (presumably very restrictive) license agreement, they'll send you the source code. I'm sure that they prohibit you from redistributing the source to anyone who hasn't also signed on to the license agreement. I would not call this "open source," since the source is not really "open." It's more like "source available" software. There are quite a few high-end commercial software packages that are like this: when you buy the package, they give you the source as well, so you (or the contractors who come to install it) can tweak it. But you can't redistribute the code afterwards, any more than you can make copies of the whole software package and redistribute it. Generally you only get the code after you've signed a whole stack of NDAs and license agreements.
I think Windows actually has an option for some buyers where they give you the source, under an extremely restrictive license. So in a very real way, this "open source" DRM project is about as open as Windows is. Which is to say, not at all.
The only way a FOSS DRM system would work would be if it relied on hardware features to hide the keys, and basically was nothing more than a wrapper around that hardware. It would 'work' because it's pushing the obfuscation that's so critical to any DRM implementation down from the software level to the hardware level. But since DRM can't exist without hiding things from the user, there's no way to implement it on an open platform.
That would make it more obnoxious but it wouldn't fundamentally change anything. You could use two computers, or maybe even just use two VMs running on a single host. If your VM system was clever and simulated the hardware well enough, the virtualized OSes might not be able to tell they're not running on actual metal, and then you could hijack the audio stream and do whatever you wanted with it.
Sure, it's probably complex for a casual user, but remember: casual users don't need to do any cracking themselves. It just takes one reasonably-competent user somewhere to do the actual cracking, and then they can distribute the unprotected file. The more onerous the DRM, the more attractive the unprotected file will be compared to the legit product.
And of course, as the content producers become more enraged at the piracy, they'll turn the DRM screws and make it more obnoxious, devaluing their own product compared to the pirated one. Barring them getting a clue, it's like quicksand: the more they struggle, the faster they sink.
My understanding of the Linux kernel development process is that only a relatively small number of people can make direct commits to the code repository. The vast majority of contributors have to send in patches to a maintainer, who then looks it over and gives it a thumbs-up/thumbs-down before committing it.
The kernel maintainers, by and large, are not stupid. So unless you are talking about getting one of them involved in your evil scheme, or being a sort of sleeper agent and worming your way up until you could get made a maintainer yourself (and you'd really need to be a maintainer of a central part of the code, not just of some driver piece somewhere, to be able to do much damage), you'd have to write your backdoor in a subtle enough way that it wouldn't be detected. That seems non-trivial, to say the least.
While I do suspect that the increasing size of the kernel does make the possibility of a malicious contribution larger, I'm not sure it's a very big threat even with that considered. The bigger problems seem to be ensuring continued high quality and cleaning out cruft, since while very little code will ever be malicious, all code will get old eventually.
I think it's a mistake to assume that everyone will do the same thing when faced with job loss. Looking back at the dot-com collapse, I know people who reacted in very different ways when they got laid off. Some got burned out on software and computers completely, took jobs that had nothing to do with IT, and in some cases never came back. They basically just put their tools down and walked away. That was it for them.
However, I know other people that didn't react that way at all; they spent a lot of time looking for jobs, sure, but it's hard even for a very highly-motivated person to spend an entire workday job hunting. And instead they spent their newly-found free time working on various "hobby" projects that they'd had on the back burner for a while. For some people it seemed to be a way of staying sharp, while for other people it was clearly just entertainment and a way to avoid getting depressed.
I know one guy who basically took his lack of a job (and his severance package) as an opportunity to mess around on his own for a while before he started job hunting; his idea was that he'd put together something on his own and then at least have something cool to talk about during interviews besides "yeah, so I worked at this company and then I got fired..." just like everyone else who was searching at the time. Not sure whether it helped him any, but it was an interesting strategy at least.
It's in no way given that when people lose their primary jobs that they'll stop doing hobbies. Frankly I'd not be surprised if people end up spending more time on their hobbies than normal, right after they lose a job.
I've always thought that would be a good system, too.
There are a lot of systems, for both email, phone, and paper-mail spam, that would work well but require some form of reliable and fast payment infrastructure to implement. That's the real sticking point.
If you had the ability to quickly and easily wire arbitrarily large or small amounts of money to someone (on a 'push' rather than 'pull' basis) without a lot of overhead, either in time or service charges, it would be practical to use micropayments or refundable charges on many kinds of messaging. I'd be all over it for email as well -- want to send me something? No problem, that'll be $1, but you'll get it back after I've read the message and confirmed that it's not spam.
In the absence of such a payment system, you might be able to approximate the same effect with CAPTCHAs, although it's not nearly as good. (Really, a CAPTCHA just requires the sender to spend time before they can communicate with you, and there's no way to easily refund their time back to them, once you've determined that they're not a spammer.)
At that point, it does not matter who the Dept. of Commerce awards the IANA contract to, since no self respecting network admin would listen to who the US Gov't claims the IANA is, rather than who the IETF says the IANA is, especially since the IETF could get the announcement published an an RFC.
That's where I'm not sure I agree with you. In a pissing contest between the U.S. Government and the IETF, I'd probably be cautious about betting against the guys with all the lawyers, guns, and money.
Major ISPs and the big software/hardware vendors in the U.S. aren't going to ignore the Federal government; heck, most of them are already deep in bed with the Feds. Just to use the 13 root nameservers as a guide, three are run directly by U.S. government agencies; two are run by major universities that almost certainly receive a lot of Federal money; two are run by VeriSign and another by Cogent, probably not likely to bite the hand that feeds; another is run by ICANN directly. The others I could see falling either way, but still you've got a big chunk that's pretty easily under the USG's thumb.
What I think would happen in the event of the crisis you describe, is that users inside the U.S. would start to get very different DNS results from people outside; a classic split root. My suspicion is that this would hurt people outside the U.S. more than it would hurt users here, and there would be a lot of pressure outside the U.S. (all the multinationals that do business here, for instance) to conform to the U.S. DNS for practical reasons of interoperability.
At any rate I don't think the situation would ever go that far, but I'm not sure that the IAB would want to play chicken if relations with the U.S. government deteriorated. (To be fair, I have no idea what their relationship is; this is all hypothetical.) But the IAB's authority is derived wholly from various administrators, especially those of major networks, implementing them voluntarily. The government, on the other hand, needs a lot less cooperation.
Slashdot Mirror
Creating custom software will always be a good business plan, and it actually gets better rather than worse as more applications become subsumed by FOSS.
Instead of trying to sell software products, which basically just treats compiled code like manufactured widgets and developers like skilled factory workers, you sell your labor.
I think that in the very long run, while there will always be some market for widget-like commercial software, it will be dwarfed by the "service sector" software industry (if it's not already) which will employ far more programmers.
This will only work if the development team can add enough compelling features to the closed-source version to prevent users from just passing it by on their way to the free version. (If it was trivial, more companies would try the open-then-closed-source maneuver.) And if they could start doing that tomorrow, they'd probably be doing a lot better at their current plan, producing closed-source add ons that enhance the FOSS platform.
The fact that they can't make the current business plan work suggests to me that either the free version meets the needs of most users, or that they're just not very good at enhancing the base version in ways that gets people to open their wallets. Neither bodes very well for them.
Offering a commercial alternative to a free software product isn't an easy or safe plan -- commercial XWindows servers have existed for years, but how many people do you know running them? -- if the free package is good enough.
Ultimately, the key is producing features that users are willing to pay for, and selling them for a price they want to pay. If you can do that, you can survive whether your business model revolves around an open-source or closed-source core; if you can't, neither will help in the long run.
They always seem to forget that the "come back with a warrant and tear your house apart" SOP also includes shooting your dog as a matter of course.
I have no idea what my neighbors are serving up.
That sounds like willful ignorance to me, at least if it's taken to an extreme. It's fairly easy to do some research and figure out what your colo's policies are, and whether they actually enforce those policies. If they don't, chances are they might not be a good place to house your server, because their attitude could come back to bite them eventually.
It's not necessary to know exactly what everyone else sharing a colo facility with you is up to, but you should at least have some measure of confidence in the colo operator to keep things above-board enough to keep the whole thing from getting shut down. If they allow illegal or generally-despised activities to go on, and develop a reputation for that sort of thing, they're risking everyone who's using the facility.
It's like renting an apartment where the landlord turns a blind eye to the meth lab downstairs; there's a limit to how far you want to take 'minding your own business.'
Using dollars is not a good metric. Food production is heavily subsidized; the price you pay for food at the grocery store in no way represents its actual costs to produce. (And it gets even worse when you try to take into account the externalities of food production that are allowed to be placed on the public without recompense -- the runoff from farms into water supplies and the Gulf, for one example.)
A better way is to look at energy and calories. The exact values depend on the food, your location, and other factors, but it's not atypical for 1 calorie of food energy to use over 100 calories of petroleum energy in its creation, transportation, packaging, and retail sale. If you buy nothing but raw foods at farmers' markets, the number will of course be lower, but even something as innocent as iceberg lettuce can have a huge energy debt. Michael Pollan does an analysis in one of his books, and if you are on the East Coast, eating lettuce from California, it's something like 4500 cal of petroleum for the measly 80 cal of human-consumable energy in the lettuce. It's much worse for heavily-processed foods.
I am a big proponent of bicycling, but it's not necessarily as obvious a win on carbon-emission grounds as it might appear. There are lots of other good reasons to bike, though. (To name a few, it decreases urban air pollution, which leads to health problems that consume resources, same also with obesity-related issues, if widely adopted it would make the roads safer, etc.)
I think of it as a "healthy / pleasant lifestyle" choice, rather than an "environmental" choice. You cannot claim to be much of an environmentalist while leading a resource-intensive, Western lifestyle. It simply cannot be done. Even the most "environmentally conscious," bike-riding, CFL-using, Prius-owning, self-righteous neo-hippies are contributing massively to the problem, practically just by getting up in the morning. You cannot eat, drink, shit, or die in America and not be contributing to the problem in some way. (You can't really even kill yourself without incurring a debt, since the way we deal with dead bodies is, in itself, not exactly environmentally sound. Although that's probably the most un-hypocritical approach.)
The truth is that individual choices matter very little in the grand scheme. If you drive an efficient vehicle, or ride a bike, great -- that's slightly less demand for gasoline, slightly lower prices, and slightly more gas for someone else to put in their Hummer (or someone in India to fuel their shiny new Tata). It's still getting pumped out of the ground as fast as we can find it either way. Our civilization is going to hurtle down the road it's going down, until it runs into something Really Bad -- maybe global warming, maybe Peak Oil, maybe something else -- and either engineers a clever way around it, or collapses in an orgy of suffering and death like nothing history has ever recorded. Whether or not you rode a bike to work won't change the outcome in the slightest.
It might make you feel a lot better, though, in the meantime. That's why I do it, and why I'd tell anyone they should as well.
You're taking on premise that Novell does more good than harm to the Linux / Free Software world. I suspect that the Boycott Novell people would disagree with that.
I haven't been firmly convinced either way, but their stance seems to be that Novell is basically Microsoft's sleeper agent, and that the OSS world would be better off if they just disappeared tomorrow, even though that would mean some of the less-evil things they're doing would stop, than if they continue. I.e., they think the continued existence of Novell, taken as a whole in its current form, is a bad thing.
I don't think either camp -- pro-Novell or anti-Novell -- is really doing a great job of making its points in a rational and unemotional way. There seems to be a lot of noise and argument but not a lot of actual substantiative discussion.
The car that ran into you took most of the damage because of the crumple zones in the front -- this is by design. Her car acted exactly as it was supposed to in a rear-end scenario.
I've often wondered this also...a few years ago there were reports that IBM was going to do it, and they had an "IBM Desktop Linux" distro waiting in the wings ... and then, nothing. Or basically nothing, what showed up was a modified version of RHEL, I think. It was anticlimactic, to say the least.
The only thing I can come up with is they're still burning from the OS/2 debacle and have an aversion to doing anything that smells like a consumer or desktop operating system. As an organization, I get the feeling they've sworn off that particular segment of the market and put it in the "never again" file.
That doesn't explain why they don't offer a server Linux tailored specifically for their hardware -- maybe just fears that it would cannibalize OS/400 (or whatever they're calling it this week) and z/OS sales? That seems logical, if shortsighted.
A few years ago it would have been massive, but even today I think it would still be significant validation for Linux if IBM actually released a distro themselves. Since a fair bit of their low-end and midrange strategy is focused on Linux, and they have a wide variety of (profitable!) software that runs on Linux, and the near-triviality of assembling a distro, plus the support revenue they'd be able to steal from RedHat or SuSE (that basically every Linux-on-IBM client is paying) ... it seems like a no-brainer to me.
Maybe they're biding their time, but more likely I think it's just the schizophrenia endemic to many large organizations, where there's just nobody in the right place with the right power to do what obviously needs to be done, so everybody instead goes their separate ways.
A very good point.
In a lot of ways I think Linux in general -- at least, "Desktop Linux" -- is held back by the same mode of thinking. There are a lot of people trying to copy Microsoft, and that just isn't going to work. You can't out-Windows Windows, (or Office). You can try, and you can perhaps even get very close, but you're inherently setting yourself up for failure: the "real thing" will always be what's being emulated, and users will pick up on that and realize they're getting something that's inherently second-rate.
The areas where Linux really leads are mostly in areas where, as a platform and in general, it doesn't try to blindly emulate Microsoft behavior, and does what's really best.
In my experience anyway, the attractiveness of 'clone' applications is overestimated by developers; users are generally quite willing to learn something new, be it an application or a workflow/process, if the new thing is obviously superior in a meaningful way ("meaningful" as in "makes their job easier"). People do this all the time; when you run into resistance is when there's relearning for no obvious gain (e.g. Office 2007).
The last time I heard about anyone getting disconnected for running a server, even anecdotally, was back in the mid-90s. This was also when the local cable internet provider was threatening to disconnect anyone who had multiple computers sharing the same connection using DNSMasq. (They wanted you to rent multiple modems and pay for essentially separate lines of service for each computer in your house.) And even then, the only person I ever heard of who actually got disconnected was pretty egregious: trying to cash in on the dot-com boom running a domain-squatting porn operation from his house.
In general, nobody really gave a crap about either restriction -- servers or DNS masquerading -- then, and nobody cares now; the only reason why I suspect they've left the bit about "no servers" in the TOS is because the providers don't want to deal with support issues, and it's an easy way to push home-office customers up to the high-priced "Business" tiers. I have never seen or experienced any effort at trying to enforce it, and even the dumbest ISPs -- at least those I've ever had -- seem to realize that ham-fistedly blocking all incoming connections would break a wide variety of applications.
And on the whole, I don't think most ISPs really care. Most home users aren't going to spring for a Business-class connection no matter what, so it's squeezing blood from a stone in any case, and so long as a few geeks running servers doesn't result in a lot of support calls or harm the network, they seem content to ignore it.
Unless you are looking at a fairly strange cross-section of consumer routers, most of them do not run Linux. Only a handful of the ones offered by Linksys, D-Link, etc. do. The majority run VxWorks, I believe.
A few years back there were actually more Linux-based routers but as cost pressures and competition have increased the manufacturers seem to have moved away in order to reduce the parts count. Broadband routers are the only pieces of equipment I've seen where the hardware specs have actually fallen, year over year, for comparable pieces of gear.
Anyway, if you do happen to get a real Linux router (like the Linksys WRT54GL, or early *G editions) and reflash the firmware to DD-WRT, you can enable IPv6. I don't think it does automatic 6to4 (at least it doesn't in the version I'm running) so it's not quite as slick as the Apple routers, but the capability is definitely there if you're running a decent load of software. I don't know if the capability is actually been removed from the kernel in stock firmwares or just not enabled.
I don't know what VxWorks' support for v6 is like, so I'm not sure how trivial it is for manufacturers to enable it, if they wanted to.
I think it should be pointed out that the definition isn't that simple. Here's a table (PDF) of how the U.S. Government defines a "small business." It varies by sector and sub-sector (a 'small' peanut farm is defined differently from a 'small' aerospace parts manufacturer, since the latter is significantly more capital intensive than the former).
Most IT-related activities are at the higher end of the spectrum (see p.30 in the PDF) which tops out at $25 million/year ("services") or 150 employees ("value added reseller"), but there are some odd special cases in there. "Technical consulting," for instance, is $7M, and "Engineering services" is only $4.5M, but "Custom Computer Programming Services" is $25M. Makes you wonder who that was gerrymandered for...
Nuclear submarines aren't necessarily perfect. I'm not sure how good the Soviets ever got at tracking ours, but it's not inconceivable that if that was the only threat, a country could get pretty creative in tracking them, and come up with some sort of first strike to take them all out at once. Maybe with some type of undersea listening network like the U.S. had (has?) in the Atlantic.
The thinking behind the nuclear "trident" of bombers, ICBMs, and submarines -- aside from keeping all three branches of the U.S. military (and the contractors that support them) happy, which is probably a large part -- is that it keeps your enemy from concentrating their energies behind a single defensive strategy. If you have all three, then your enemy would have to build a SAM and early-warning system to shoot down the bombers, anti-missile technology to intercept the ICBMs, and ASW systems to go after the submarines. It's not practical. But if you only had one, they'd be able to focus their efforts and might be able to produce a viable defense.
When ever you try to assign gender on anything except the Chromosomes it will fail.
Actually it fails pretty spectacularly when you try to determine it based on chromosomes, too. There are XY women with androgen insensitivity syndrome (AIS), and both XXY and XYY men. In many cases, especially those of AIS, they may go their whole lives without knowing that their chromosomes convey something different than their sex organs.
And using sex organs starts to fail as well when you get into intersexed and transgendered people; someone's sex organs may not match the gender they 'pass' as in social contexts, or that they prefer to be treated as.
It is anything but a black and white issue.
Persistent internet connectivity is definitely one of those things I never thought I'd find useful, but now that I have it in the form of a smartphone, I'm never going back. Like from-my-cold-dead-hands never.
First, being able to send and receive email anywhere is neat. This may not be quite as impressive to people who've been on unlimited-SMS plans for a while, but I never got into text messaging. Push email on the other hand has definitely changed how I work. (And does seem like a potential source of work/life imbalance; I keep the push feature turned off after hours.)
Services like Google Maps are suddenly a lot more useful when used from a GPS-enabled smartphone than I'd ever realized they were before (and I'd been a big fan of them on my computer, too). It's done to walking around what having a navigation unit did to driving; I can basically go out and not really be terribly worried about getting somewhere, or looking up a store's hours, or finding the nearest [whatever] near [someplace]. It is worth getting a smartphone with GPS for this purpose alone, IMO.
Being able to do a quick Google search anywhere, pretty much at the drop of a hat, is also nice. I think it's one of those things that will pretty quickly become second-nature to a lot of people; even the people who don't actually have phones that can do it themselves, quickly learn that other people do and expect the ability to be there. Wikipedia is a little ugly on my phone at least, but it's handy to have access to as well.
My bank, Amtrak, and Delta Airlines all have mobile sites up and running now, and it seems to becoming more common daily. It is really nice to be able to look and see, as soon as you hit the tarmac, whether your connecting flight is still on-time or been delayed (meaning: do you need to haul ass off the plane, or can you wait and let everyone else get off first?).
There's also software that lets you use a 802.11-capable handset (at least Symbian ones) as an access point, which is great if you want an alternative to finicky Bluetooth or USB tethering, or you want to share your cell data connection with a group of people in a remote location. That's saved me a lot of headaches. (Software is JoikuSpot, I'm a big fan.)
I can see how nothing that a smartphone does is really impossible to do with a small laptop and free wireless connections -- and that was the route I took, for several years -- but there's really very little comparison. I don't carry my laptop around nearly as much since getting the smartphone, and I haven't felt like the money for the data service was anything but a great deal since getting it, either.
That would be one solution, and a good one at that, but it's non-trivial. The hardware players have their keys stored in secure memory and I'm not sure what it would take to extract -- maybe you could do it in a good university lab somewhere.
So far I think there has only been success in extracting the keys used by software players, which can be disabled in later disc pressings. (The GP's description of how key distribution and encryption works is a little simplified from reality; there's a truly bizarre revocation scheme shoehorned in there that's quite complex.)
In fact I think that the granularity of player keys is significantly higher than just one key per model of player. It may go down to the level of individual players, akin to serial numbers, although I'm not entirely sure there.
Perhaps because it's a blatantly obvious cash-grab by an organization whose ostensible purpose is to serve the Internet community, but instead lives off of it parasitically?
Perhaps because it would require many people to register multiple domain names (possibly thousands) in order to protect their brands, or else leave them open to be registered by squatters and phishers.
Perhaps because there's just no legitimate technical reason for it?
Perhaps because it would be a giant pain in the ass and probably break various pieces of software, requiring people who have no interest in the issue either way to expend energy on it?
Those are just the things that come immediately to mind.
Yep, that's my question too. I was excited for a minute, thinking that I'd be able to suddenly use my Gmail/Google ID to sign into various OpenID-enabled sites ... but then they went and fucked it up.
They might as well have not bothered. The whole point of OpenID is interoperability. If they don't want to play along with the consensus, they shouldn't bother trying.
I'd really hope that whoever owns the OpenID trademark comes after them and forces them to stop calling whatever they're doing "OpenID". If it's not compatible with an existing specification, it's not OpenID. They will risk seriously devaluing their trademark if they allow incompatible implementations to use the name. They need to be ruthless about this. Google can do whatever it wants and call it "GoogleID", but if it's called "OpenID", it needs to be compatible with everyone else claiming to be that.
"Temporarily" means that time was wasted. People had to re-discover something that was previously known. That, optimally, should never happen.
That someone had to re-discover something means that the original discovery was forgotten; that's what we'd all (I hope) like to avoid. Time spent rediscovering things that were already known in the past is time that can't be spent actually making new progress; society suffers if we have a spotty collective memory.
AFICT:
1. This is *not* Free Software. You are correct in thinking that Free Software is fundamentally incompatible with (software) DRM. There's just no way to make it work. The user freedom that's part of the very definition of what constitutes Free Software means that anyone with half a brain could reverse-engineer the DRM implementation, extract the key, and generally have their way with the content. This isn't a bug, it's a feature.
2. This is only "open source" in the most minimal, literal sense. Basically, if you sign some sort of (presumably very restrictive) license agreement, they'll send you the source code. I'm sure that they prohibit you from redistributing the source to anyone who hasn't also signed on to the license agreement. I would not call this "open source," since the source is not really "open." It's more like "source available" software. There are quite a few high-end commercial software packages that are like this: when you buy the package, they give you the source as well, so you (or the contractors who come to install it) can tweak it. But you can't redistribute the code afterwards, any more than you can make copies of the whole software package and redistribute it. Generally you only get the code after you've signed a whole stack of NDAs and license agreements.
I think Windows actually has an option for some buyers where they give you the source, under an extremely restrictive license. So in a very real way, this "open source" DRM project is about as open as Windows is. Which is to say, not at all.
The only way a FOSS DRM system would work would be if it relied on hardware features to hide the keys, and basically was nothing more than a wrapper around that hardware. It would 'work' because it's pushing the obfuscation that's so critical to any DRM implementation down from the software level to the hardware level. But since DRM can't exist without hiding things from the user, there's no way to implement it on an open platform.
That would make it more obnoxious but it wouldn't fundamentally change anything. You could use two computers, or maybe even just use two VMs running on a single host. If your VM system was clever and simulated the hardware well enough, the virtualized OSes might not be able to tell they're not running on actual metal, and then you could hijack the audio stream and do whatever you wanted with it.
Sure, it's probably complex for a casual user, but remember: casual users don't need to do any cracking themselves. It just takes one reasonably-competent user somewhere to do the actual cracking, and then they can distribute the unprotected file. The more onerous the DRM, the more attractive the unprotected file will be compared to the legit product.
And of course, as the content producers become more enraged at the piracy, they'll turn the DRM screws and make it more obnoxious, devaluing their own product compared to the pirated one. Barring them getting a clue, it's like quicksand: the more they struggle, the faster they sink.
My understanding of the Linux kernel development process is that only a relatively small number of people can make direct commits to the code repository. The vast majority of contributors have to send in patches to a maintainer, who then looks it over and gives it a thumbs-up/thumbs-down before committing it.
The kernel maintainers, by and large, are not stupid. So unless you are talking about getting one of them involved in your evil scheme, or being a sort of sleeper agent and worming your way up until you could get made a maintainer yourself (and you'd really need to be a maintainer of a central part of the code, not just of some driver piece somewhere, to be able to do much damage), you'd have to write your backdoor in a subtle enough way that it wouldn't be detected. That seems non-trivial, to say the least.
While I do suspect that the increasing size of the kernel does make the possibility of a malicious contribution larger, I'm not sure it's a very big threat even with that considered. The bigger problems seem to be ensuring continued high quality and cleaning out cruft, since while very little code will ever be malicious, all code will get old eventually.
I think it's a mistake to assume that everyone will do the same thing when faced with job loss. Looking back at the dot-com collapse, I know people who reacted in very different ways when they got laid off. Some got burned out on software and computers completely, took jobs that had nothing to do with IT, and in some cases never came back. They basically just put their tools down and walked away. That was it for them.
However, I know other people that didn't react that way at all; they spent a lot of time looking for jobs, sure, but it's hard even for a very highly-motivated person to spend an entire workday job hunting. And instead they spent their newly-found free time working on various "hobby" projects that they'd had on the back burner for a while. For some people it seemed to be a way of staying sharp, while for other people it was clearly just entertainment and a way to avoid getting depressed.
I know one guy who basically took his lack of a job (and his severance package) as an opportunity to mess around on his own for a while before he started job hunting; his idea was that he'd put together something on his own and then at least have something cool to talk about during interviews besides "yeah, so I worked at this company and then I got fired..." just like everyone else who was searching at the time. Not sure whether it helped him any, but it was an interesting strategy at least.
It's in no way given that when people lose their primary jobs that they'll stop doing hobbies. Frankly I'd not be surprised if people end up spending more time on their hobbies than normal, right after they lose a job.
I've always thought that would be a good system, too.
There are a lot of systems, for both email, phone, and paper-mail spam, that would work well but require some form of reliable and fast payment infrastructure to implement. That's the real sticking point.
If you had the ability to quickly and easily wire arbitrarily large or small amounts of money to someone (on a 'push' rather than 'pull' basis) without a lot of overhead, either in time or service charges, it would be practical to use micropayments or refundable charges on many kinds of messaging. I'd be all over it for email as well -- want to send me something? No problem, that'll be $1, but you'll get it back after I've read the message and confirmed that it's not spam.
In the absence of such a payment system, you might be able to approximate the same effect with CAPTCHAs, although it's not nearly as good. (Really, a CAPTCHA just requires the sender to spend time before they can communicate with you, and there's no way to easily refund their time back to them, once you've determined that they're not a spammer.)
At that point, it does not matter who the Dept. of Commerce awards the IANA contract to, since no self respecting network admin would listen to who the US Gov't claims the IANA is, rather than who the IETF says the IANA is, especially since the IETF could get the announcement published an an RFC.
That's where I'm not sure I agree with you. In a pissing contest between the U.S. Government and the IETF, I'd probably be cautious about betting against the guys with all the lawyers, guns, and money.
Major ISPs and the big software/hardware vendors in the U.S. aren't going to ignore the Federal government; heck, most of them are already deep in bed with the Feds. Just to use the 13 root nameservers as a guide, three are run directly by U.S. government agencies; two are run by major universities that almost certainly receive a lot of Federal money; two are run by VeriSign and another by Cogent, probably not likely to bite the hand that feeds; another is run by ICANN directly. The others I could see falling either way, but still you've got a big chunk that's pretty easily under the USG's thumb.
What I think would happen in the event of the crisis you describe, is that users inside the U.S. would start to get very different DNS results from people outside; a classic split root. My suspicion is that this would hurt people outside the U.S. more than it would hurt users here, and there would be a lot of pressure outside the U.S. (all the multinationals that do business here, for instance) to conform to the U.S. DNS for practical reasons of interoperability.
At any rate I don't think the situation would ever go that far, but I'm not sure that the IAB would want to play chicken if relations with the U.S. government deteriorated. (To be fair, I have no idea what their relationship is; this is all hypothetical.) But the IAB's authority is derived wholly from various administrators, especially those of major networks, implementing them voluntarily. The government, on the other hand, needs a lot less cooperation.