Well, as other people have pointed out, that wasn't the point of this study. This study was just to make sure that the drug was safe enough so that they could conduct more large-scale studies to determine it's efficacy at actually preventing AIDS.
However, I think that we can assume that in making the drug, before recruiting testers at all, they have probably done in vitro tests to determine that it makes exposed cells more resistant to HIV infection. (Otherwise, why bother doing Phase 1 trials?)
When you get larger sample sizes, then you can do in vivo studies. Not by actually injecting people with HIV and seeing if the vaccine made them immune (calling Dr. Mengele!) but by splitting the study participants into several groups, and giving some the actual vaccine and some a placebo, and then measuring the rates of HIV/AIDS infection in the two groups. This helps to cancel out any difference in behavior that people might have, as a result of getting the vaccination. It's pretty standard.
I don't think that anyone (except whoever wrote the summary) is saying that the 49-person study proved that it was actually effective against HIV in vivo. It's going to take more work to show that; right now they just need to make sure it's not going to kill the people they inject with it.
Software encryption is really superior to hardware in many ways. Basically the only way it's usually not superior is in terms of speed, and this is why you see hardware encryption implemented.
However, as general-purpose computers have gotten faster and faster, so that there's more surplus capacity for things like encryption and decryption on the fly, I see the need for hardware encryption becoming less and less.
There's just no reason to restrict yourself to a hardware-based system that's hard to upgrade and fix, when you can use a software system that can be kept in tune with the state of the art and is a lot easier to trust. Even if I'm a relatively interested and intelligent person, there's no way I can 'open up' a hardware encryption module and see what's going on inside. With software encryption, I can look at the source code (and provided I'm using a trusted compiler and toolchain) know what it's doing.
Furthermore, software encryption leads to more diversity in implementations. When you use hardware systems, the only way they're affordable is if there is an economy of scale. You don't make just a handful (or even a few thousand) hardware modules, you want to make tens or hundreds of thousands of them. That means it's automatically going to be a big target. With software, everyone can use something that fits their needs more completely, and the exposure of the system as a result of a single exploit is reduced.
Hardware encryption was fine when computers were too slow to encrypt data that was being written to disk on-the-fly. But now they are, and this means that you can use regular equipment, and use whatever cryptographic implementation you want, and upgrade it as often as is required, with minimal additional expense. In fact, if I was going to build a "hardware" encryption device today, I'd probably just design it around a general-purpose system-on-a-chip so that it would be easily reprogrammable. I can't imagine that for anything but the most specialized, very speed-intensive tasks, that a custom-made hardware solution is really advantageous.
Not that I'm saying that all cryptographic hardware is bad; there is definitely room for specialized components without making entire hardware encryptors: dedicated hardware random number generators, for instance, seem like they'll definitely have a place for the foreseeable future.
At least that I can tell (correct me if I'm wrong) as a regular end-user, who's only looking to purchase a single unit, you can't even get the bare hard drive model. It seems like on their website, that it only comes with Windows XP.
It's only people looking to buy in quantity (although they say small accounts are acceptable, I think they mean "no individuals") who can get the ones designed to use Linux, with a bare HD and assumedly some small discount for not taking the MSFT license.
All in all, pretty crappy.
I think if you really want to get a bare laptop without an OS, your best bet is to get one from Retrobox or similar, as a used model. They're all sold bare, because most of them come from corporations that had site licenses and can't sell an individual OS license when they liquidate the physical asset of the machine. I guess you could argue that there is always some "Microsoft tax" built into the price of any used machine that previously came with Windows, regardless of its current configuration, but at least you don't actually have to feel like you're buying it. If that's important to you.
Huh? I don't know what you're talking about, because I fired up a fresh VMWare machine a few weeks ago, installed a bare WinXP system onto it, and just for fun started using Internet Explorer to browse the 'net. I let this go for a day, with a couple of people using it just for web browsing, and the thing got totally infested with viruses and spyware. I had originally thought it would be interesting to try and decontaminate the system without reformatting it, but eventually I just gave up and rolled back the VM. A few more days and I probably would have been spewing a million penis-enlargement emails a minute.
The only thing that keeps most Windows users' computers in a useable state is the piles and piles of anti-adware, anti-spyware, anti-intrusion, anti-virus software. The bare OS and browser are still pretty horrible. All you have to do is click on that "This page requires an ActiveX control, do you want to install it?" button once, and you're totally infested with popups and spyware.
I don't know where you got from my post that I was saying that Linux doesn't have any problems. On the contrary, I was saying that I think there's a missed opportunity at work when people lambast iTunes, since frankly it's a pretty lame piece of software in some ways, and Apple can't make it substantially less-lame because they're too deeply in bed with the music labels.
However, I disagree with you completely about DRM. I think you're in the minority in wanting to give up what has to be the greatest advantage of Linux versus any other proprietary OS, it's openness, in order to play encrypted music. With a closed-source kernel, Linux isn't anything. It's just another UNIX clone, and we all know what happened to the rest of that field. There's no organization big enough to really support Linux in a closed-source configuration and prevent it from being less functional than an open-source one, so you'd just be relegating yourself to using a braindead OS and being permanently dependent on the whims of some vendor.
Honestly, if that's what you want, go get a Mac. It's not Linux, but it's basically everything else you're talking about.
Frankly, I've yet to see any application of DRM that made me think it was worth the cost. I don't want to "rent" my music so desperately that it affects my choice of operating system.
Heck, give me half that--$85 million--and I'll develop the friggin' system myself.
You'd probably think so, but I bet after the first few months of totally contradictory change requests, specification creep, and an utter lack of hard-and-fast acceptance criteria, that you'd throw up your hands, too.
You can blame the contractors all you want, but I've worked on a bunch of projects like this, and they almost always fail not because the developers weren't good or didn't know their stuff, but because there wasn't somebody on the client side who had the political (internal/office-politics, not Democrats/Republicans politics, although within the USG they're often related) capital to get all the little fiefdoms that exist inside a big organization and sit them down and say "Okay, Fuckheads: this is the system we're going to be using, this is how it's going to work, and you will use it."
Projects like this fail when you let every Tom, Dick and Harry start pushing features into it. I've seen situations where software is in the final stages of testing, and somebody decides that it would be fun to bring down the Big Boss to show them where all these millions of dollars have been spent. And the Boss will come down and take one look at the software, and immediately demand that something get changed. Often I don't think that they really care about what they're demanding, they just want to show off that they have the power to change shit, so they do.
It's stuff like that which pushes projects into failure, even if they look dead simple on paper. The problem isn't a software-engineering one, it's a customer-relations one. It's a problem of the people hiring the developers probably not having a good idea of what they wanted in software, and not having a single person in charge of it.
You can tell that happened with this FBI project, because it's obvious just from the summary that the CIO wasn't involved in the project throughout its lifecycle. He just seemingly walked in on it when it was a month away from deployment, at which point I'm sure everything was totally FUBAR. The way to have prevented this would have been to get somebody like that on board from the very beginning, who could have kicked ass and taken names and kept things under control.
Without good leadership on the client side, and a clear set of business processes, requirements, and acceptance criteria, it's not surprising that these large software projects fail as often as they do. However, as long as the failures are equally profitable to the development contracting companies as the successes, they have no problem taking on a contract even though they know the client is going to drive it into the ground and has no idea what they want./rant
Well, this has further cemented my opinion that while the Zune certainly would make me very, very afraid if I were the CEO of Creative, I'm not sure that it would have me shaking in my boots if I was in Steve Jobs' position.
I think it stands a chance of being clearly superior to all the other iPod wannabes, and basically wipe up their market-share and send them into some other line of work, particularly because of the WiFi feature, but there's just nothing compelling about it that would displace the iPod.
I have no doubt that Microsoft will capture close to 100% of the market: but the "market" for this device is "MP3 players other than iPods."
Have you completely ignored the astroturfing campaign, including TV ads, that attacked Net Neutrality in specious ways? Do you really believe the MPAA did not have anything to do with that?
I think AT&T, Comcast, and the rest of the telcos are perfectly capable of hiring a PR firm and buying some TV time. Nothing about that implies the involvement of the MPAA.
If this is really a deal-breaker for that many people (and I really don't think that it would be, if the alternative to iTunes was that clearly superior), then it seems like the easiest solution would be to put a feature in the Linux software that would act as an analog audio recorder.
Simply connect a patch cable from your Windows PC or Mac running iTunes to your Linux box (or you could do it all in software by running iTunes in a Virtual Machine), fire up your "Purchased Music" playlist, and the Linux machine could record it all to a DRM-free format, and maybe even break it into individual files (using Auto Gain Control). There are probably even ways that you could use the XML file which iTunes happily exports for you in order to input the metadata for the new un-DRMed files.
Or you could just instruct people to burn their purchased music out to a CD-RW, and import it from that. Again, you could use the iTunes Library to get metadata for the songs, so from a user's perspective it would be basically seamless.
Sure, there would be quality loss, but for people who find 128kbit MP3s acceptable, I doubt it would be noticeable.
And of course there's always the "nuclear option," which is to develop a lossless de-DRMer for iTMS-purchased files. If it was made as a plugin and distributed only on non-US servers, it wouldn't contaminate the rest of the suite legally, and that would pretty much take care of it. Naturally you'd have to commit to an ongoing cat-and-mouse game with Apple, since assumedly they'd change the file format at every opportunity, but they're limited by needing to be compatible with iPods.
As deal-breaking problems go, that one's pretty minor. If I can think of three possible solutions in five minutes, there are probably many others that haven't even occured to me.
Remember that Apple's iTunes music is encoded with its DRM. So you cannot legally play iTunes-encoded music on the iPod.
This is an absolutely untrue statement.
Hopefully it's just being spoken out of ignorance and not malice, but at any rate, it's misleading.
iTunes encodes music that you rip from a CD to bog standard MP3 files, WAV files, AIFF files, or AAC files. With the exception of AAC files, which despite being an open format may not have a Linux codec, all of them work equally well on all platforms, using any number of different players.
The only DRMed files which get produced by iTunes (and I'm not really sure whether it's even fair to say that iTunes makes them per se) are the files purchased from the iTunes Music Store. Those are the 99-cents-a-song ones.
Maybe I don't hang out with a rich enough crowd, but I don't know anyone with more than a dozen or so iTMS-purchased tracks, and I know a lot of iTunes users. It's just not practical to buy an iPod which holds 20,000 songs and fill it up at $1 a song. As I've said before, the only people who can afford to do that, probably also have someone who's job it is to buy music for them, and don't give a damn which software it uses anyway.
It is an outright lie to say that iTunes encodes music to a DRMed format, given that the great majority of people's files do not come from the Music Store, but from CDs. The only software I know that ever did that was a Sony product that came with MD players, and ripped CDs to an DRMed ATRAC format, and an early version of Windows Media Player, which ripped CDs to WMV format.
I don't think anyone is really asking for support for M4P (those would be the encrypted, DRMed files purchased from the iTunes Media Store) files on Linux. Everyone realizes, I think, that there's no way to do DRM with open-source software, and frankly I think this is a Good Thing.
However, people use iTunes and iPods for a lot more than DRMed music. There is this tendency here on Slashdot to assume that everyone who uses iTunes or owns an iPod has purchased lots of music for it from the iTMS. This is not true, and in fact is provably wrong. The vast majority of music on most people's portable devices and in their music libraries, comes from ripped CDs (or from peer to peer).
Linux would be doing well if it could just come up with a library management program that was as good as iTunes is, and it would be doing better than iTunes if it made it as easy to download music OFF of the iPod as it is to put it on. (That is, to do the magical and frightening-to-media-companies "reverse syncronization.")
iTunes had a large userbase long before the Music Store existed: it gained popularity (back when it was a Mac-only program) because it has a good interface for managing a lot of songs and playlists. I have yet to see (although if someone wants to point one out I'd be interested) a Linux application that is the equal of it. All the Linux programs seem to assume that the OS' file browser is the best way to manage music, and that small single-purpose tools should be used to do syncronization or updating.
I remember what managing a large MP3 collection was like before nice library management programs were developed to automatically sort files into folders by Artist/Album, and it sucked. The file browser--even a good general-purpose browser (like Konqueror)--is not the tool for this job.
While this is very true to the "UNIX way," it's not what people want. People want big, monolithic, do-everything applications. They want something that's a media player, a library manager, a file uploader, an ID3 tag editor, and a portable-device-syncronization manager. If you could build a BitTorrent client and P2P browser into that at the same time, that would be great, too.
iTunes isn't good because of the Music Store, it's good despite it. There is a huge, gaping hole that the Linux community could fill if people desired to, for a program that's BETTER than iTunes: one that works seamlessly with the iPod but also works with other music stores (non-DRMed ones: AllOfMp3.com, eMusic, etc., plus free sources), and doesn't shy away from features because it would piss off music companies (sharing/streaming of music, true bidirectional syncronization).
Apple's software is hobbled by the company's relationship with the media companies and the necessity of flogging their own music store, not strengthened by it. It means that they have to produce crippled software, which doesn't do everything that it could otherwise. The FOSS community could run circles around iTunes; heck, they could make the closest thing that Linux has to a 'killer app' for home users. Going on about DRM is just a red herring; only a very few people can afford to buy large quantities of music from iTMS anyway, the great majority wouldn't be stopped by that from moving to a clearly superior piece of software, if one existed. To my knowledge, it does not. And that's why iTunes reigns supreme.
Now, I'm not a game developer, but it's always seemed to me like lots of aspects of gaming that we take as gospel are really consequences of the technology that was available when "multimedia" games were first developed. We assume, for instance, that storage will be cheaper than processing power. This has always been true: when you had a 66MHz processor with a 1.2 GB hard drive, with a CD-Rom drive, it made sense to pre-render as much stuff as you possibly could and stick it on the disc. Computers got faster, but at the same time DVDs came along, so the status quo stayed about the same.
But what if this isn't the best way to do things? What if game consoles add processing power faster than they add storage? Rather than storing huge texturemaps, you render them on the fly. The quality of the rendered textures could depend on what system you were using and how much processing capacity it had. If you had the entry-level unit, it might look pretty plain. If you had a super-duper multiprocessor system, then it would start to look better and better.
Maybe textures are a bad example, because it's hard to imagine having enough processing power in everyone's consoles to really make generating them advantageous to having them prerendered, but then again, people have thought a lot of things were impossible and they usually end up being wrong eventually.
Level maps might also be candidates for runtime generation, at least in single-player games; rather than trying to store huge urban environments (where you always have the problem of the player running into the edge), you could have some rules for generating the map as the player moved. As the person moved around, previously explored areas would be saved to the console's online storage (hard drive). It doesn't seem like it would be hard to generate very detailed urban environments algorithmically. Mapping out every piece of litter and broken payphone in a world the size of Manhattan would be both labor and space-intensive, but you could probably find out the distribution rules for litter and payphones pretty easily, and have the computer do it as needed.
I think there could be interesting consequences of a system like this. Provided the games were programmed correctly, the same game could be used on a range of systems, from very minimal pocket systems (where, lacking processing capacity, it would use very minimal stored textures), to all-out gaming rigs, where separate processors would handle map generation, texture generation, traditional graphics, enemy AI, physics, and player input.
It seems like the console manufacturers could stand to benefit from something like this, because there would always be an upgrade path. I guess it's an open question whether the game developers would: if you make a game too open-ended and it doesn't come with a subscription fee, would they see it as a threat?
I don't think that the GP ever claimed that all of Sun's hardware was overpriced, or for that matter that IBM's hardware wasn't equally overpriced. Frankly I think they're both damned expensive, although I think as you scale into the high end, that it becomes very hard to compare one two the other.
At any rate, your price comparison doesn't really address the GP's point, namely that Sun is a hardware company, and IBM is a services and consulting company. Sun's products are always going to be, like Apple, designed around the concept of selling more hardware. IBM's hardware, on the other hand, is really an entre so that they can sell you a whole lot of maintainance/consulting/"transformation" services.
It's a question of business models, and which company really is more compatible with open source in general. I think they both could be, but IBM is a bit closer to the model which seems to have worked for other OSS companies so far.
The people who care about their privacy are already using encryption or other systems to protect their privacy (like face to face meetings).
The rest of the population just doesn't give a damn. Not valuing their privacy, they don't see it as a tradeoff at all, just an increase in their personal security at no particular cost.
I don't think, or at least I've never heard, that any of the software on the system would support DRM.
Nobody that I know of has ever proposed a good open-source DRM system, to the point where I'm beginning to think that it's impossible. DRM is security through obscurity; obscurity is anathema to open-source software; therefore it's very hard to try to implement DRM on an OSS platform, unless you use binary blobs or something.
The use of systems like this, combined with strong licensing (if you could make the libraries for the system GPL instead of LGPL, so that it would be difficult to write closed-source software that would run on them) then it might guarantee that there wouldn't be any DRMed eBooks for them.
And that would be, in my mind, a very Good Thing. I can't really think of many more disturbing informational concepts than the idea of a book that burns itself; particularly when you give that to kids so that they accept it as part of the way things ought to work.
Give it six months after the first really big deployment (not this one; this is just 500 units, basically prototypes) and they'll be all over eBay.
Subsidizing the hell out of something and send it to the Third World is a good way to guarantee that it'll end up being sold right back to the First World, if there's any kind of demand.
That said, they also occasionally remove features.
A while back, they had a great feature: they let you download your friends' addresses and other contact information as VCard-format files, which you could import into your local addressbook.
This was brilliant. Frankly it was better than any LDAP-type or Active Directory system I'd used; and it meant that my local address book suddenly had stuff like postal addresses, birthdays, plus email addresses in it. I'd never had the time to hand-enter that stuff in the past, and Facebook was a one-stop directory for contact information. On my Mac, once I got the information from the Facebook export into Address Book, people's birthdays automatically got added to my calendar, too. It was just a really nice, integrated system. I expected that the next step would be to give some sort of an open API, so that you could connect directly rather than having to export as a file and import it on the client machine.
Instead, they killed the feature. Completely. It really ruined a lot of the usefulness of Facebook for me, because now if I want to use any of the information that's there, I have to retype it manually into my address book. I'm not sure what their motivation was for getting rid of it, if it was spam-related or if they wanted to try to discourage people from taking information out of the site, and then not having to come back to the site and view their ads as frequently, but I was pretty disappointed.
I'm hopeful that maybe with this API, they'll bring some of that usefulness back.
After all, what is a "social networking" site really, once you get past the buzzword-itis? It's really a very smart, well-organized, user-driven information directory (at least this is how most people use it). To be able to use something like your Facebook friends list as your Address Book when writing emails or anything else, would make a lot of sense.
Also, unlike MySpace, Facebook doesn't give me the urge to go out and stab people for making me try to look at their attempts to write HTML.
Whoever thought it was a good idea to let regular people design their own webpages needs to be put in front of a monitor, Clockwork Orange-style, and made to look at the results of their handiwork, forever.
Facebook does it right: you enter your information into little text blocks, and it generates the page. It's easy to search and link, because everything's categorized, and it doesn't encourage homicide.
Interesting. Not exactly front-page coverage, but I guess we'll take what we can get.
FYI, I think the most direct way that a person would find them, without a direct link to the page, is by clicking:
Dell.com > Desktops > Small Business > Open Source Desktops (bottom right)
Clicking on any of the "normal" desktops on the Consumer or Small Business page do not give you Linux as an option, and you never get Linux as an option in the same menu as Windows; you have to make the decision between "Open Source Desktops" and the regular desktops before you get to a configuration screen.
It's certainly a step in the right direction, but there's definitely a bit of a 'Linux Ghetto' being created. If you're not specifically looking for the Linux models, you're never going to see them.
Did anyone else find it more than slightly ironic, given the discussion about Moveable Type and its move from donationware to crippleware, what the guy's blog is run with?
That's right, it's... WordPress.
You know, the FOSS/GPL competitor to Moveable Type, which gained popularity in no small part because of the exodus of users from Moveable Type circa version 3.0, when they tried to cripple the free personal version. (I won't say that WP was created in response to that, because it wasn't and has existed as far back as 2001 in various incarnations, but it's hard to avoid noting that it definitely got popular as a result of MT's licensing fiasco.)
I think it's also worth noting that Moveable Type has since restored their personal version to full-feature status; although I don't know what their exact motivations are, it seems inconceivable that the competition from Free sources wasn't part of the decision.
I think there's a lesson here, but I'll leave determining what that is as an exercise for the reader.
I'm not really sure what the best solution is, aside from offering the software under some sort of a less-than-Free license that requires a fee for commercial or government use. Obviously, that's GPL-incompatible.
Maybe the solution is to offer support contracts that sort of correspond to various levels of the software, or sell "retail box" editions which on paper seem superior to whatever you're giving away for free. This could be as easy as making the free version use a different name than the one that you sell in a box for a few bucks -- that way if a PHB questions the purchase, they can't say that the exact same item was available for free.
Given the number of government and commercial users who have big budgets and traditionally bankroll a lot of software development, finding a way to derive income from these sources is a big deal if you want to ensure that programmers stay in business. I'm honestly not sure if there's a good solution: it's hard to both give something away for Free, and at the same time get money from an entity that is sworn to try and be as cheap and stingy as possible.
Poor people, both today and in the past, have never really been able to afford much 'art.' Generally, all they can afford is copies. (About the only exception to this is theater, where you can afford actual labor-intensive art, because you pool your resources with a lot of other people.)
Cheap mechanical reproduction shouldn't be confused with actual artistic output. The reproduction has little in the way of actual inherent value, since it contains very little labor. We are used to paying more for copies than they are actually worth (by a stored-labor-value reckoning), because of an artificial scarcity of copies. This is only possible because until recently, most people didn't have the capability of making another copy of a work themselves, and thus the people that did could charge an inflated price for each copy.
In the model that I think would be the most sustainable, the cost of copies of artwork would go down dramatically; in fact it would probably trend towards zero (although never actually reach it). As people desired actual new content, a demand would develop, and people would pay artists to create it, either individually or as part of a group. The mechanics of how this might happen are infinitely variable; it could be as basic as outright patronage, or as complicated as some form of micropayment system to encourage an artist you particularly liked. It's not necessarily limited to the rich, because the middle class would not be paying as much for their 'copies of art' as they are now, and could probably afford to contribute somewhat.
Yes, I agree there would probably be a net reduction in the amount of new art being created, but I don't think that's a bad thing. Right now you have a market that doesn't want and isn't interested in paying for most of what's being produced. There's not necessarily a public interest in just having things created for no particular reason; it would be better that the supply of "new art" was matched more closely to the demand, and thus the number of people attempting to produce art (of whatever sort) as a career would not exceed the demand quite so much as they do now.
Although you certainly have a point regarding the lack of documentation in most, if not all, freeware distributions, the problem is not quite so severe in the commercial distros. Most of the userland tools in RHEL are pretty well documented, for instance, and you can get paper manuals and books for it if you want to.
(I almost went with RHEL for that reason, but in the end I decided that I couldn't go to an RPM-based distro; I have too many bad memories of dependency hell, even if they have tried to make it almost as good as apt-get with the whole yum system. But since using Debian, I've decided that "apt-get install foo" is how software and computing in general ought to work; when you want new software, you tell the computer to install it.)
The hardware compatibility isn't so much of an issue if you have a standard hardware configuration, like you might if you were doing a big deployment. It's a problem for oddball hardware, in particular wireless stuff, but I'm not sure that it impacts a rollout at a school, assumedly across a wired network to a lot of basically-identical machines, than it does a home user with a lot of crappy Best Buy-acquired hardware. Also, there aren't too many video cards that aren't supported in basic modes using default drivers; for non-gaming use, having accelerated 3D support isn't that important, and that's the real Catch-22 with Linux. The majority of school and office PCs around use low-end integrated graphics anyway, and Linux is pretty good there. (Actually with the whole Intel open-source drivers, it will probably get better.)
You're right, there is a lot of room for improvement in Linux in general, but I'm not sure there's anything you can point to in particular and say that the Linux developers ought to be doing differently. If the vendors don't document their hardware, it's difficult to write drivers; the 'solution' to this is that the vendors need to document their stuff, not that the Linux developers need to put the vendors' crappy driver binaries into the kernel (the security reasons alone ought to put that idea to rest). There's no "quick fix" here, aside from hoping that market pressure will cause vendors to give up the idea that somehow their APIs are trade secrets when what they make money off of is hardware sales.
In terms of documentation on the software side, I agree that there is a rather serious problem. Frankly I think it's endemic to the way that OSS software is developed. Even if you were someone who wanted to volunteer your time and write documentation for a particular software project, you'd basically have nothing to work with besides the source code and the finished product itself. For whatever reason--maybe it's because so many programmers deal with it in their day jobs and don't like having to do it--there's very little documentation (analysis, specifications, technical documentation, process/flow descriptions) created in OSS projects, and these are what you'd use when writing documentation. However, despite the fact that my background in heavily top-down managed commercial projects tells me that the OSS model just shouldn't work, it does; in fact it works pretty well. So any changes to it for the benefit of writing documentation, have to be carefully balanced against the gains that have been made by doing nothing but releasing source code and a few READMEs, and letting the programmers spend all of their time writing code instead of specifications.
Slashdot Mirror
Well, as other people have pointed out, that wasn't the point of this study. This study was just to make sure that the drug was safe enough so that they could conduct more large-scale studies to determine it's efficacy at actually preventing AIDS.
However, I think that we can assume that in making the drug, before recruiting testers at all, they have probably done in vitro tests to determine that it makes exposed cells more resistant to HIV infection. (Otherwise, why bother doing Phase 1 trials?)
When you get larger sample sizes, then you can do in vivo studies. Not by actually injecting people with HIV and seeing if the vaccine made them immune (calling Dr. Mengele!) but by splitting the study participants into several groups, and giving some the actual vaccine and some a placebo, and then measuring the rates of HIV/AIDS infection in the two groups. This helps to cancel out any difference in behavior that people might have, as a result of getting the vaccination. It's pretty standard.
I don't think that anyone (except whoever wrote the summary) is saying that the 49-person study proved that it was actually effective against HIV in vivo. It's going to take more work to show that; right now they just need to make sure it's not going to kill the people they inject with it.
I'm not sure I agree with this.
Software encryption is really superior to hardware in many ways. Basically the only way it's usually not superior is in terms of speed, and this is why you see hardware encryption implemented.
However, as general-purpose computers have gotten faster and faster, so that there's more surplus capacity for things like encryption and decryption on the fly, I see the need for hardware encryption becoming less and less.
There's just no reason to restrict yourself to a hardware-based system that's hard to upgrade and fix, when you can use a software system that can be kept in tune with the state of the art and is a lot easier to trust. Even if I'm a relatively interested and intelligent person, there's no way I can 'open up' a hardware encryption module and see what's going on inside. With software encryption, I can look at the source code (and provided I'm using a trusted compiler and toolchain) know what it's doing.
Furthermore, software encryption leads to more diversity in implementations. When you use hardware systems, the only way they're affordable is if there is an economy of scale. You don't make just a handful (or even a few thousand) hardware modules, you want to make tens or hundreds of thousands of them. That means it's automatically going to be a big target. With software, everyone can use something that fits their needs more completely, and the exposure of the system as a result of a single exploit is reduced.
Hardware encryption was fine when computers were too slow to encrypt data that was being written to disk on-the-fly. But now they are, and this means that you can use regular equipment, and use whatever cryptographic implementation you want, and upgrade it as often as is required, with minimal additional expense. In fact, if I was going to build a "hardware" encryption device today, I'd probably just design it around a general-purpose system-on-a-chip so that it would be easily reprogrammable. I can't imagine that for anything but the most specialized, very speed-intensive tasks, that a custom-made hardware solution is really advantageous.
Not that I'm saying that all cryptographic hardware is bad; there is definitely room for specialized components without making entire hardware encryptors: dedicated hardware random number generators, for instance, seem like they'll definitely have a place for the foreseeable future.
At least that I can tell (correct me if I'm wrong) as a regular end-user, who's only looking to purchase a single unit, you can't even get the bare hard drive model. It seems like on their website, that it only comes with Windows XP.
It's only people looking to buy in quantity (although they say small accounts are acceptable, I think they mean "no individuals") who can get the ones designed to use Linux, with a bare HD and assumedly some small discount for not taking the MSFT license.
All in all, pretty crappy.
I think if you really want to get a bare laptop without an OS, your best bet is to get one from Retrobox or similar, as a used model. They're all sold bare, because most of them come from corporations that had site licenses and can't sell an individual OS license when they liquidate the physical asset of the machine. I guess you could argue that there is always some "Microsoft tax" built into the price of any used machine that previously came with Windows, regardless of its current configuration, but at least you don't actually have to feel like you're buying it. If that's important to you.
No, but I think they're calling it "SkyNet."
Huh? I don't know what you're talking about, because I fired up a fresh VMWare machine a few weeks ago, installed a bare WinXP system onto it, and just for fun started using Internet Explorer to browse the 'net. I let this go for a day, with a couple of people using it just for web browsing, and the thing got totally infested with viruses and spyware. I had originally thought it would be interesting to try and decontaminate the system without reformatting it, but eventually I just gave up and rolled back the VM. A few more days and I probably would have been spewing a million penis-enlargement emails a minute.
The only thing that keeps most Windows users' computers in a useable state is the piles and piles of anti-adware, anti-spyware, anti-intrusion, anti-virus software. The bare OS and browser are still pretty horrible. All you have to do is click on that "This page requires an ActiveX control, do you want to install it?" button once, and you're totally infested with popups and spyware.
I don't know where you got from my post that I was saying that Linux doesn't have any problems. On the contrary, I was saying that I think there's a missed opportunity at work when people lambast iTunes, since frankly it's a pretty lame piece of software in some ways, and Apple can't make it substantially less-lame because they're too deeply in bed with the music labels.
However, I disagree with you completely about DRM. I think you're in the minority in wanting to give up what has to be the greatest advantage of Linux versus any other proprietary OS, it's openness, in order to play encrypted music. With a closed-source kernel, Linux isn't anything. It's just another UNIX clone, and we all know what happened to the rest of that field. There's no organization big enough to really support Linux in a closed-source configuration and prevent it from being less functional than an open-source one, so you'd just be relegating yourself to using a braindead OS and being permanently dependent on the whims of some vendor.
Honestly, if that's what you want, go get a Mac. It's not Linux, but it's basically everything else you're talking about.
Frankly, I've yet to see any application of DRM that made me think it was worth the cost. I don't want to "rent" my music so desperately that it affects my choice of operating system.
Heck, give me half that--$85 million--and I'll develop the friggin' system myself.
/rant
You'd probably think so, but I bet after the first few months of totally contradictory change requests, specification creep, and an utter lack of hard-and-fast acceptance criteria, that you'd throw up your hands, too.
You can blame the contractors all you want, but I've worked on a bunch of projects like this, and they almost always fail not because the developers weren't good or didn't know their stuff, but because there wasn't somebody on the client side who had the political (internal/office-politics, not Democrats/Republicans politics, although within the USG they're often related) capital to get all the little fiefdoms that exist inside a big organization and sit them down and say "Okay, Fuckheads: this is the system we're going to be using, this is how it's going to work, and you will use it."
Projects like this fail when you let every Tom, Dick and Harry start pushing features into it. I've seen situations where software is in the final stages of testing, and somebody decides that it would be fun to bring down the Big Boss to show them where all these millions of dollars have been spent. And the Boss will come down and take one look at the software, and immediately demand that something get changed. Often I don't think that they really care about what they're demanding, they just want to show off that they have the power to change shit, so they do.
It's stuff like that which pushes projects into failure, even if they look dead simple on paper. The problem isn't a software-engineering one, it's a customer-relations one. It's a problem of the people hiring the developers probably not having a good idea of what they wanted in software, and not having a single person in charge of it.
You can tell that happened with this FBI project, because it's obvious just from the summary that the CIO wasn't involved in the project throughout its lifecycle. He just seemingly walked in on it when it was a month away from deployment, at which point I'm sure everything was totally FUBAR. The way to have prevented this would have been to get somebody like that on board from the very beginning, who could have kicked ass and taken names and kept things under control.
Without good leadership on the client side, and a clear set of business processes, requirements, and acceptance criteria, it's not surprising that these large software projects fail as often as they do. However, as long as the failures are equally profitable to the development contracting companies as the successes, they have no problem taking on a contract even though they know the client is going to drive it into the ground and has no idea what they want.
Well, this has further cemented my opinion that while the Zune certainly would make me very, very afraid if I were the CEO of Creative, I'm not sure that it would have me shaking in my boots if I was in Steve Jobs' position.
I think it stands a chance of being clearly superior to all the other iPod wannabes, and basically wipe up their market-share and send them into some other line of work, particularly because of the WiFi feature, but there's just nothing compelling about it that would displace the iPod.
I have no doubt that Microsoft will capture close to 100% of the market: but the "market" for this device is "MP3 players other than iPods."
Have you completely ignored the astroturfing campaign, including TV ads, that attacked Net Neutrality in specious ways? Do you really believe the MPAA did not have anything to do with that?
I think AT&T, Comcast, and the rest of the telcos are perfectly capable of hiring a PR firm and buying some TV time. Nothing about that implies the involvement of the MPAA.
If this is really a deal-breaker for that many people (and I really don't think that it would be, if the alternative to iTunes was that clearly superior), then it seems like the easiest solution would be to put a feature in the Linux software that would act as an analog audio recorder.
Simply connect a patch cable from your Windows PC or Mac running iTunes to your Linux box (or you could do it all in software by running iTunes in a Virtual Machine), fire up your "Purchased Music" playlist, and the Linux machine could record it all to a DRM-free format, and maybe even break it into individual files (using Auto Gain Control). There are probably even ways that you could use the XML file which iTunes happily exports for you in order to input the metadata for the new un-DRMed files.
Or you could just instruct people to burn their purchased music out to a CD-RW, and import it from that. Again, you could use the iTunes Library to get metadata for the songs, so from a user's perspective it would be basically seamless.
Sure, there would be quality loss, but for people who find 128kbit MP3s acceptable, I doubt it would be noticeable.
And of course there's always the "nuclear option," which is to develop a lossless de-DRMer for iTMS-purchased files. If it was made as a plugin and distributed only on non-US servers, it wouldn't contaminate the rest of the suite legally, and that would pretty much take care of it. Naturally you'd have to commit to an ongoing cat-and-mouse game with Apple, since assumedly they'd change the file format at every opportunity, but they're limited by needing to be compatible with iPods.
As deal-breaking problems go, that one's pretty minor. If I can think of three possible solutions in five minutes, there are probably many others that haven't even occured to me.
Remember that Apple's iTunes music is encoded with its DRM. So you cannot legally play iTunes-encoded music on the iPod.
This is an absolutely untrue statement.
Hopefully it's just being spoken out of ignorance and not malice, but at any rate, it's misleading.
iTunes encodes music that you rip from a CD to bog standard MP3 files, WAV files, AIFF files, or AAC files. With the exception of AAC files, which despite being an open format may not have a Linux codec, all of them work equally well on all platforms, using any number of different players.
The only DRMed files which get produced by iTunes (and I'm not really sure whether it's even fair to say that iTunes makes them per se) are the files purchased from the iTunes Music Store. Those are the 99-cents-a-song ones.
Maybe I don't hang out with a rich enough crowd, but I don't know anyone with more than a dozen or so iTMS-purchased tracks, and I know a lot of iTunes users. It's just not practical to buy an iPod which holds 20,000 songs and fill it up at $1 a song. As I've said before, the only people who can afford to do that, probably also have someone who's job it is to buy music for them, and don't give a damn which software it uses anyway.
It is an outright lie to say that iTunes encodes music to a DRMed format, given that the great majority of people's files do not come from the Music Store, but from CDs. The only software I know that ever did that was a Sony product that came with MD players, and ripped CDs to an DRMed ATRAC format, and an early version of Windows Media Player, which ripped CDs to WMV format.
Don't spread FUD.
I don't think anyone is really asking for support for M4P (those would be the encrypted, DRMed files purchased from the iTunes Media Store) files on Linux. Everyone realizes, I think, that there's no way to do DRM with open-source software, and frankly I think this is a Good Thing.
However, people use iTunes and iPods for a lot more than DRMed music. There is this tendency here on Slashdot to assume that everyone who uses iTunes or owns an iPod has purchased lots of music for it from the iTMS. This is not true, and in fact is provably wrong. The vast majority of music on most people's portable devices and in their music libraries, comes from ripped CDs (or from peer to peer).
Linux would be doing well if it could just come up with a library management program that was as good as iTunes is, and it would be doing better than iTunes if it made it as easy to download music OFF of the iPod as it is to put it on. (That is, to do the magical and frightening-to-media-companies "reverse syncronization.")
iTunes had a large userbase long before the Music Store existed: it gained popularity (back when it was a Mac-only program) because it has a good interface for managing a lot of songs and playlists. I have yet to see (although if someone wants to point one out I'd be interested) a Linux application that is the equal of it. All the Linux programs seem to assume that the OS' file browser is the best way to manage music, and that small single-purpose tools should be used to do syncronization or updating.
I remember what managing a large MP3 collection was like before nice library management programs were developed to automatically sort files into folders by Artist/Album, and it sucked. The file browser--even a good general-purpose browser (like Konqueror)--is not the tool for this job.
While this is very true to the "UNIX way," it's not what people want. People want big, monolithic, do-everything applications. They want something that's a media player, a library manager, a file uploader, an ID3 tag editor, and a portable-device-syncronization manager. If you could build a BitTorrent client and P2P browser into that at the same time, that would be great, too.
iTunes isn't good because of the Music Store, it's good despite it. There is a huge, gaping hole that the Linux community could fill if people desired to, for a program that's BETTER than iTunes: one that works seamlessly with the iPod but also works with other music stores (non-DRMed ones: AllOfMp3.com, eMusic, etc., plus free sources), and doesn't shy away from features because it would piss off music companies (sharing/streaming of music, true bidirectional syncronization).
Apple's software is hobbled by the company's relationship with the media companies and the necessity of flogging their own music store, not strengthened by it. It means that they have to produce crippled software, which doesn't do everything that it could otherwise. The FOSS community could run circles around iTunes; heck, they could make the closest thing that Linux has to a 'killer app' for home users. Going on about DRM is just a red herring; only a very few people can afford to buy large quantities of music from iTMS anyway, the great majority wouldn't be stopped by that from moving to a clearly superior piece of software, if one existed. To my knowledge, it does not. And that's why iTunes reigns supreme.
Now, I'm not a game developer, but it's always seemed to me like lots of aspects of gaming that we take as gospel are really consequences of the technology that was available when "multimedia" games were first developed. We assume, for instance, that storage will be cheaper than processing power. This has always been true: when you had a 66MHz processor with a 1.2 GB hard drive, with a CD-Rom drive, it made sense to pre-render as much stuff as you possibly could and stick it on the disc. Computers got faster, but at the same time DVDs came along, so the status quo stayed about the same.
But what if this isn't the best way to do things? What if game consoles add processing power faster than they add storage? Rather than storing huge texturemaps, you render them on the fly. The quality of the rendered textures could depend on what system you were using and how much processing capacity it had. If you had the entry-level unit, it might look pretty plain. If you had a super-duper multiprocessor system, then it would start to look better and better.
Maybe textures are a bad example, because it's hard to imagine having enough processing power in everyone's consoles to really make generating them advantageous to having them prerendered, but then again, people have thought a lot of things were impossible and they usually end up being wrong eventually.
Level maps might also be candidates for runtime generation, at least in single-player games; rather than trying to store huge urban environments (where you always have the problem of the player running into the edge), you could have some rules for generating the map as the player moved. As the person moved around, previously explored areas would be saved to the console's online storage (hard drive). It doesn't seem like it would be hard to generate very detailed urban environments algorithmically. Mapping out every piece of litter and broken payphone in a world the size of Manhattan would be both labor and space-intensive, but you could probably find out the distribution rules for litter and payphones pretty easily, and have the computer do it as needed.
I think there could be interesting consequences of a system like this. Provided the games were programmed correctly, the same game could be used on a range of systems, from very minimal pocket systems (where, lacking processing capacity, it would use very minimal stored textures), to all-out gaming rigs, where separate processors would handle map generation, texture generation, traditional graphics, enemy AI, physics, and player input.
It seems like the console manufacturers could stand to benefit from something like this, because there would always be an upgrade path. I guess it's an open question whether the game developers would: if you make a game too open-ended and it doesn't come with a subscription fee, would they see it as a threat?
I don't think that the GP ever claimed that all of Sun's hardware was overpriced, or for that matter that IBM's hardware wasn't equally overpriced. Frankly I think they're both damned expensive, although I think as you scale into the high end, that it becomes very hard to compare one two the other.
At any rate, your price comparison doesn't really address the GP's point, namely that Sun is a hardware company, and IBM is a services and consulting company. Sun's products are always going to be, like Apple, designed around the concept of selling more hardware. IBM's hardware, on the other hand, is really an entre so that they can sell you a whole lot of maintainance/consulting/"transformation" services.
It's a question of business models, and which company really is more compatible with open source in general. I think they both could be, but IBM is a bit closer to the model which seems to have worked for other OSS companies so far.
The people who care about their privacy are already using encryption or other systems to protect their privacy (like face to face meetings).
The rest of the population just doesn't give a damn. Not valuing their privacy, they don't see it as a tradeoff at all, just an increase in their personal security at no particular cost.
I don't think, or at least I've never heard, that any of the software on the system would support DRM.
Nobody that I know of has ever proposed a good open-source DRM system, to the point where I'm beginning to think that it's impossible. DRM is security through obscurity; obscurity is anathema to open-source software; therefore it's very hard to try to implement DRM on an OSS platform, unless you use binary blobs or something.
The use of systems like this, combined with strong licensing (if you could make the libraries for the system GPL instead of LGPL, so that it would be difficult to write closed-source software that would run on them) then it might guarantee that there wouldn't be any DRMed eBooks for them.
And that would be, in my mind, a very Good Thing. I can't really think of many more disturbing informational concepts than the idea of a book that burns itself; particularly when you give that to kids so that they accept it as part of the way things ought to work.
Give it six months after the first really big deployment (not this one; this is just 500 units, basically prototypes) and they'll be all over eBay.
Subsidizing the hell out of something and send it to the Third World is a good way to guarantee that it'll end up being sold right back to the First World, if there's any kind of demand.
Whatever it is that has the name 9XXX, I want one.
I think a Palm would be the obvious choice.
That said, they also occasionally remove features.
A while back, they had a great feature: they let you download your friends' addresses and other contact information as VCard-format files, which you could import into your local addressbook.
This was brilliant. Frankly it was better than any LDAP-type or Active Directory system I'd used; and it meant that my local address book suddenly had stuff like postal addresses, birthdays, plus email addresses in it. I'd never had the time to hand-enter that stuff in the past, and Facebook was a one-stop directory for contact information. On my Mac, once I got the information from the Facebook export into Address Book, people's birthdays automatically got added to my calendar, too. It was just a really nice, integrated system. I expected that the next step would be to give some sort of an open API, so that you could connect directly rather than having to export as a file and import it on the client machine.
Instead, they killed the feature. Completely. It really ruined a lot of the usefulness of Facebook for me, because now if I want to use any of the information that's there, I have to retype it manually into my address book. I'm not sure what their motivation was for getting rid of it, if it was spam-related or if they wanted to try to discourage people from taking information out of the site, and then not having to come back to the site and view their ads as frequently, but I was pretty disappointed.
I'm hopeful that maybe with this API, they'll bring some of that usefulness back.
After all, what is a "social networking" site really, once you get past the buzzword-itis? It's really a very smart, well-organized, user-driven information directory (at least this is how most people use it). To be able to use something like your Facebook friends list as your Address Book when writing emails or anything else, would make a lot of sense.
Also, unlike MySpace, Facebook doesn't give me the urge to go out and stab people for making me try to look at their attempts to write HTML.
Whoever thought it was a good idea to let regular people design their own webpages needs to be put in front of a monitor, Clockwork Orange-style, and made to look at the results of their handiwork, forever.
Facebook does it right: you enter your information into little text blocks, and it generates the page. It's easy to search and link, because everything's categorized, and it doesn't encourage homicide.
Interesting. Not exactly front-page coverage, but I guess we'll take what we can get.
FYI, I think the most direct way that a person would find them, without a direct link to the page, is by clicking:
Dell.com > Desktops > Small Business > Open Source Desktops (bottom right)
Clicking on any of the "normal" desktops on the Consumer or Small Business page do not give you Linux as an option, and you never get Linux as an option in the same menu as Windows; you have to make the decision between "Open Source Desktops" and the regular desktops before you get to a configuration screen.
It's certainly a step in the right direction, but there's definitely a bit of a 'Linux Ghetto' being created. If you're not specifically looking for the Linux models, you're never going to see them.
Did anyone else find it more than slightly ironic, given the discussion about Moveable Type and its move from donationware to crippleware, what the guy's blog is run with?
... WordPress.
That's right, it's
You know, the FOSS/GPL competitor to Moveable Type, which gained popularity in no small part because of the exodus of users from Moveable Type circa version 3.0, when they tried to cripple the free personal version. (I won't say that WP was created in response to that, because it wasn't and has existed as far back as 2001 in various incarnations, but it's hard to avoid noting that it definitely got popular as a result of MT's licensing fiasco.)
I think it's also worth noting that Moveable Type has since restored their personal version to full-feature status; although I don't know what their exact motivations are, it seems inconceivable that the competition from Free sources wasn't part of the decision.
I think there's a lesson here, but I'll leave determining what that is as an exercise for the reader.
This is a good point.
I'm not really sure what the best solution is, aside from offering the software under some sort of a less-than-Free license that requires a fee for commercial or government use. Obviously, that's GPL-incompatible.
Maybe the solution is to offer support contracts that sort of correspond to various levels of the software, or sell "retail box" editions which on paper seem superior to whatever you're giving away for free. This could be as easy as making the free version use a different name than the one that you sell in a box for a few bucks -- that way if a PHB questions the purchase, they can't say that the exact same item was available for free.
Given the number of government and commercial users who have big budgets and traditionally bankroll a lot of software development, finding a way to derive income from these sources is a big deal if you want to ensure that programmers stay in business. I'm honestly not sure if there's a good solution: it's hard to both give something away for Free, and at the same time get money from an entity that is sworn to try and be as cheap and stingy as possible.
Poor people, both today and in the past, have never really been able to afford much 'art.' Generally, all they can afford is copies. (About the only exception to this is theater, where you can afford actual labor-intensive art, because you pool your resources with a lot of other people.)
Cheap mechanical reproduction shouldn't be confused with actual artistic output. The reproduction has little in the way of actual inherent value, since it contains very little labor. We are used to paying more for copies than they are actually worth (by a stored-labor-value reckoning), because of an artificial scarcity of copies. This is only possible because until recently, most people didn't have the capability of making another copy of a work themselves, and thus the people that did could charge an inflated price for each copy.
In the model that I think would be the most sustainable, the cost of copies of artwork would go down dramatically; in fact it would probably trend towards zero (although never actually reach it). As people desired actual new content, a demand would develop, and people would pay artists to create it, either individually or as part of a group. The mechanics of how this might happen are infinitely variable; it could be as basic as outright patronage, or as complicated as some form of micropayment system to encourage an artist you particularly liked. It's not necessarily limited to the rich, because the middle class would not be paying as much for their 'copies of art' as they are now, and could probably afford to contribute somewhat.
Yes, I agree there would probably be a net reduction in the amount of new art being created, but I don't think that's a bad thing. Right now you have a market that doesn't want and isn't interested in paying for most of what's being produced. There's not necessarily a public interest in just having things created for no particular reason; it would be better that the supply of "new art" was matched more closely to the demand, and thus the number of people attempting to produce art (of whatever sort) as a career would not exceed the demand quite so much as they do now.
Although you certainly have a point regarding the lack of documentation in most, if not all, freeware distributions, the problem is not quite so severe in the commercial distros. Most of the userland tools in RHEL are pretty well documented, for instance, and you can get paper manuals and books for it if you want to.
(I almost went with RHEL for that reason, but in the end I decided that I couldn't go to an RPM-based distro; I have too many bad memories of dependency hell, even if they have tried to make it almost as good as apt-get with the whole yum system. But since using Debian, I've decided that "apt-get install foo" is how software and computing in general ought to work; when you want new software, you tell the computer to install it.)
The hardware compatibility isn't so much of an issue if you have a standard hardware configuration, like you might if you were doing a big deployment. It's a problem for oddball hardware, in particular wireless stuff, but I'm not sure that it impacts a rollout at a school, assumedly across a wired network to a lot of basically-identical machines, than it does a home user with a lot of crappy Best Buy-acquired hardware. Also, there aren't too many video cards that aren't supported in basic modes using default drivers; for non-gaming use, having accelerated 3D support isn't that important, and that's the real Catch-22 with Linux. The majority of school and office PCs around use low-end integrated graphics anyway, and Linux is pretty good there. (Actually with the whole Intel open-source drivers, it will probably get better.)
You're right, there is a lot of room for improvement in Linux in general, but I'm not sure there's anything you can point to in particular and say that the Linux developers ought to be doing differently. If the vendors don't document their hardware, it's difficult to write drivers; the 'solution' to this is that the vendors need to document their stuff, not that the Linux developers need to put the vendors' crappy driver binaries into the kernel (the security reasons alone ought to put that idea to rest). There's no "quick fix" here, aside from hoping that market pressure will cause vendors to give up the idea that somehow their APIs are trade secrets when what they make money off of is hardware sales.
In terms of documentation on the software side, I agree that there is a rather serious problem. Frankly I think it's endemic to the way that OSS software is developed. Even if you were someone who wanted to volunteer your time and write documentation for a particular software project, you'd basically have nothing to work with besides the source code and the finished product itself. For whatever reason--maybe it's because so many programmers deal with it in their day jobs and don't like having to do it--there's very little documentation (analysis, specifications, technical documentation, process/flow descriptions) created in OSS projects, and these are what you'd use when writing documentation. However, despite the fact that my background in heavily top-down managed commercial projects tells me that the OSS model just shouldn't work, it does; in fact it works pretty well. So any changes to it for the benefit of writing documentation, have to be carefully balanced against the gains that have been made by doing nothing but releasing source code and a few READMEs, and letting the programmers spend all of their time writing code instead of specifications.