Yeah, whatever. You can't trust Java for anything remotely numeric, it's broken, it's a fact. Anyone who's read professor Kahan's (Berkeley) How JAVA's Floating-Point Hurts Everyone Everywhere papers, and followed the issue for a little time will run like the devil from Java... I mean, modelling disease involves differential equations. You have to be crazy to use Java. C is much more trustworthy in that respect. In fact, this knowledge should be widespread. It's sad to see so many people take for granted that something a big company did is flawless.;-)
Man, I had the same problem! (see my post somewhere else). I wrote a paper and got whipped by OO.org bugs! Lost a whole point in my grade for that.
Miracle you weren't modded as "flamebait" by the OO.org fanboy crowd.
Yeah, I mean what's up with all this intellectual dishonesty that some are displaying here, saying there aren't any compatibility issues, that OO.org is just great?
If you don't live in a nice smug LaTeX bubble (that is, if you don't work in the Math department), you _know_ the M$ Word drones will come after you, eventually, with an incompatible file.
And here is half-ass solution: whenever people send stuff in.doc format, I complain to them, explaining there are over 10 operating systems I could install on my computer right now that have e-mail, browser, etc. Only one of them has MS Word. And then I say "could you please be so kind as to generate the file in a truly universal format?"
Good question. Here's my experience, which is bound to be modded as flamebait by/. OpenOffice fanboys:
I've stretched OpenOffice more than your average zealot, choosing it to write a full report, as I had no M$ system available and needed to interoperate with the general LaTeX-phobic population. It was a disaster, and this was when it was considered "stable" and not beta. In fact, it was beta software. It had a bug that, misteriously, corrupted all page numbering. And I couldn't get the numbering correct again, ever, having to deliver it like that, apologizing for a "bug in the software." Of course, that penalized me.
Also, inserting a large amount of color images almost brought it to grind...I was definitely pissed off...And there wasn't any time to be filling out bug reports.
Recently, I've tested OpenOffice 1.1.3. It had such basic bugs still, like (for instance) I couldn't write "São Paulo" (I need the til in my native language - Portuguese). Frankly, I don't care what people say, OpenOffice is below standard. You can hype it all you want, you can go bezerk with open source zealotry (*), OpenOffice is beta software, period. Now, please, if all you do is write 3 pages and save in.doc format, don't bother posting your opinion, thank you very much.
Don't get me wrong, I love the idea of a Libre Software office package, but this isn't it. I'm hoping AbiWord will get there. I builds everywhere (unlike Java), and it has plug-ins, so I'm hoping it'll develop to be an interesting thing.
(*) Now, I'm not only pissed off with the bugs, I'm also pissed off with the Java dependency. This fixation on Java should develop in a C# (Mono) fixation because, frankly, I understand the point of avoiding C++, and Java is a no go in BSD (because it's not libre software).
Sure, that's the default answer. But, I don't know much about the Linux kernel, so allow me this little speculation:
How is the kernel affected by desktop requirements? How does enterprise use vs. game use shape issues like memory, and threading? Are there any issues vis-à-vis these differences? That's an interesting question, in which case, if there are, would there be an impact, since there is fundamental design interdependece between them? Here's an interesting paper by MIT (and the abstract):
Maintainability of the Linux Kernel Schach, Jin, Wright, Heller & Offutt
"We have examined 365 versions of Linux. For every version, we counted the number of instances of common (global) coupling between each of the 17 kernel modules and all the other modules in that version of Linux. We found that the number of instances of common coupling grows exponentially with version number. This result is significant at the 99.99% level, and no additional variables are needed to explain this increase. We conclude that, unless Linux is restructured with a bare minimum of common coupling, the dependencies induced by common coupling will, at some future date, make Linux exceedingly hard to maintain without inducing regression faults."
Also:
Categorization of Common Coupling and Its Application to the Maintainability of the Linux Kernel, by Liguo Yu, Stephen R. Schach, Kai Chen, Jeff Offutt, IEEE Computer Society http://csdl.computer.org/comp/trans/ts/20 04/10/e06 94abs.htm
"Data coupling between modules, especially common coupling, has long been considered a source of concern in software design, but the issue is somewhat more complicated for products that are comprised of kernel modules together with optional nonkernel modules. This paper presents a refined categorization of common coupling based on definitions and uses between kernel and nonkernel modules and applies the categorization to a case study. Common coupling is usually avoided when possible because of the potential for introducing risky dependencies among software modules. The relative risk of these dependencies is strongly related to the specific definition-use relationships. In a previous paper, we presented results from a longitudinal analysis of multiple versions of the open-source operating system Linux. This paper applies the new common coupling categorization to version 2.4.20 of Linux, counting the number of instances of common coupling between each of the 26 kernel modules and all the other nonkernel modules. We also categorize each coupling in terms of the definition-use relationships. Results show that the Linux kernel contains a large number of common couplings of all types, raising a concern about the long-term maintainability of Linux."
Fuck that: don't give developing countries $100 computers, give them the $1000 ones that are being wasted on the so called developed countries - hey they're already developed, so they shouldn't need them, right?
Although I empathize with your troubles teaching spoiled kids, I have to say I found the technologies mentioned in this/. post pretty amazing, and found them to be in sharp contrast with what is being done in my own country.
I live in Brazil and just today I read in the morning newspaper about PC Conectado, which is supposed to be Brazil's answer to the problem of computer technology for the masses, and I found those technologies (the $100,00 laptop, the simputer, and the loband thing) to be quite an advance in terms empowering technology, concepts, and efforts to bring technology to the people.
The PC Conectado, in contrast, will sell for R$1,400 (that's US$ 535 at today's exchange rate). The high-fallutin' high-priests of Brazil's Free Software community are ecstatic because it'll come loaded with F/OSS software. That's good, but Brazil's minimum wage is R$ 260,00 ( = US$ 99 ), so PC Conectado is way expensive. In fact, it appears to be a stripped-down PC, and costing around what a stripped-down PC costs. It's not as cheap as it ought to be. Wal-Mart, the cheapo department store in USA, has 'puters for less (I've checked here today.)
So, in contrasting these 3 projects with the PC Conectado, I found nice food-for-thought. Here are my 2 cents futurology and thoughts:
1) While Free Software is nice, it may not be what people want, because it might not correspond to what people expect. It might just be that when people learn they can't play Windows warez games or office software in PC Conectado, they will uninstall GNU/Linux. Currently, for medium wage jobs in Brazil, the job market demmands some expertise in Windows software, and some might want to buy a PC to get that expertise and hone skills in Excel or whatever. If your hardware allows shifting to Windows, will they stick to GNU/Linux? I don't think so...
2) What is really needed is cheap hardware. You can't cheat like PC Conectado. You need $ 100 laptops. Cheap means cheap.
3) If you have custom hardware, there is no "turning back" to proprietary software.
4) Research groups must focus on new concepts. Old concepts will not only cost more, they might backfire. When you take low income populations, their whole model of what's "top" might be what is the dominant technology (and we know that's not the best choice).
5) Internet access is not a luxury. It's as much of a luxury as library access is a luxury. "The net is the computer." (TM Sun Microsystems):-)
6) Hand in hand with this custom new hardware an net technologies, we need to teach children what computer programming is.Developing countries do *not* need government-subsidized programs to teach people to use Microsoft software. In the long run, this will empower developing countries and create a virtuous circle.
So, IMHO, "the $1000 ones [computers] that are being wasted on the so called developed countries" isn't gonna cut it. I really think governments of developing world must foster research groups with innovative ideas.
McVoy contributed more than $500 000 worth of software to the osdl
I am curious as to how one gets at such a figure (seriously). Does he count all the developers using the FAIB (free-as-in-beer) version and then adds that to BK developer time? Or does he also calculate "if these guys were not supporting BK, they would develop for non-FAIB BK"?
Here's the way Linus views the difference between Samba and BK:
Anobody that compares that to Open Office (or even samba, which Tridge did write) is an idiot. Open office and samba are constructive projects that actually do something useful,and are technically advanced quite regardless of the fact that they can interoperate with the competition. They look at the file data because they then _use_ it (...)" (I bolded it).
Just so one has more context, before he said that, he also said: "Tridge could have done something constructive: he could have written the best damn SCM on the planet, and believed that open source generates better things, and competed against BitKeeper that way. (...) But that's not what Tridge did. He didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about."
You know, when he/she said that, I wondered if he/she ever read dpkg's source code... A decade later and Debian developer don't even have decent documentation of a central piece in their distro. I
what exactly is the issue for which the Debian project's choice of packaging technology is a problem?
Look for a thread (not mine) called "Binary Compatibility Is Hard(TM)" for interesting insights. I've elaborated some more in other threads, but they weren't moderated up much. You have to realize dpkg is very old. It's code is a mess, it's undocumented. Anyone trying to improve that would probably get ignored on religious basis (in fact, Alfredo Kojima of WindowMaker/Conectiva fame did that with apt-rpm). Debian's packaging mechanism involves quite a bit of human handwork. This bogged down the project. I believe it was one of the main factors. Look for an AC thread called "Metcalfe's Law", too.
is the issue for which the manner in which Debian is handled as a social project is a problem?
I believe it's a problem because, in Debian, every "developer" gets to vote and thereby steer the project in this or that direction. I think even "developer" is a misnomer, because a lot of those guys are just maintainers. In FreeBSD land they would be called "commiters." A lot of them are not people who can really hack deep things like protocols and kernel. Compare them with BSD developers and you will see what I mean. Debian is too much of a democracy, instead of a meritocracy. So in the end, you get this situation where the organization slows to a halt. This happened. For real. Look at it. Also, let me just remind you that the winner of the DPL title this year also thinks there are problems with Debian's social organization and constitution.
The Debian project team seems committed to having 'stable' mean stable, 'testing' mean not stable
Please, get it over it. Use a BSD for an experience of "stable" and "up-to-date" (I was not always a BSD zealot, I used to be a Debian diehard).
That's a 5 right there! One of the best pieces of all. Shameless plug: somewhere else here I've expressed my view that maybe the fundamental problem with Debian - possibly what originates all others - is their packaging technology. They treat it like a religion, even though it was written, IIRC, almost a decade ago. You have achieved great insight with your piece. In fact, it's so obvious that one wonders why so many miss these simple facts. Also read an AC post called "Metcalfe's law", which wasn't justly moderated, about the growth of Debian packages being N^2.
PS: You don't always install from source on BSDs, you can install packages (for things that are too big, like KDE, etc). Also, might wanna read up on how GoboLinux approaches these issue, and also the pkgsrc documentation (see here for some insights on installing "incompatible" stuff).
Ubuntu wants to work with debian, to make a better debian, but the goals of Ubuntu and Debian are different. debian aims at a pure FOSS os, while ubuntu aims at a viable commercial desktop linux distro.A viable commercial Linux require a lot of 'free as in beer' software to run properly (...) Even though i have sarge, i installed both of the above (...) because I needed (...).
See, all Debian fanboys install non-free software. just read Planet Debian.
Let me inaugurate two new concepts: free-enough-for-me free software
and really-free free software. Linux is FEFM, because more and more binaries from companies get in the kernel. Once that trend starts, it doesn't stop. OpenBSD is RFFS, because Theo de Raadt will spit on your face if you even propose to have binaries, and will drop support for your dear hardware. That is, he believes in the market economy: "Oh, don't wanna contribute so we can write drivers? Fine, we'll go buy from someone else." See, you can use the market to your favor. Linus fanboys must learn that.
Call me a zealot, and a troll, I don't care. I tell the truth. Once those little binaries creep in, once you give in to the suits, you're fucked. It's not free software anymore. They have no respect. It's all money to them. Freedom and ethics are better, but some just don't think so. So stop this Debian fanboy hipocrisy, all this jive about "a pure OS."
Debian Developers, they spend years trying to get their software to work on archs that no one ever uses any more
It always seems like they're incesing their glorified self when they say that. However, if you judge them by an objective comparison, you just have to compare them with NetBSD, which supports far more architectures and yet, are able to maintain their distro up-to-date. Plus, they don't only hack at userland software, but also on kernel and protocols, while Debian just does security and packaging. So, by all accounts, Debian needs to stop justifying their mistakes with shitty excuses.
As a simple example, a package might be excluded from Debian 'testing' due to a build failure on any of the 11 architectures supported by Debian 'sarge', but it is still suitable for Ubuntu if it builds and works on only three of them. A package will also be prevented from entering Debian 'testing' if it has release-critical bugs according to Debian criteria, but a bug which is release-critical for Debian may not be as important for Ubuntu.
I believe you gave a crystal-clear explanation with one of Debian's deepest problems. Why must all the packages in all those architectures be in sync? It's artificial. If it doesn't work, it doesn't work. Until it does. Period. Put a machine-readable info somewhere about this status, and comparison charts on the web. Tough luck, no developer resources/interest/time enough, and keep the dharma wheel moving.
I would like to see the leadership of the two organizations get together, discuss the idea, and hopefully agree that this is a good way to work together. The leadership can then promote co-maintainership as a 'best practice' within their own organizations, inform the userbase (i.e. get it mentioned on slashdot), PLUS appoint an interoperability liason.
Seriously, don't you think all that is up to Debian? I think Ubuntu may or may not agree, but I don't see them having a problem. You got yourseleves into a quagmire. You must do something about it. Debian used to have a lot of respect, but you lost a lot of it...Stop acting like Ubuntu is the problem. Ubuntu is the solution. For most of ex-Debian users.
I don't mean to be rude, but you gotta develop focus on the issue. The problem is Debian and how it's handled as a social project, and its choice of software packaging technology.
RPM was poorly designed from the start, and was probably designed from the start as a tool for vendor lock-in. Apt-get, AFAICT, is well designed.
I used to think apt-get was great, and that rpm sucked. Until I looked at dpkg's source code, and found undocumented funtions like void ohshit. Come to think of it, it's still undocumented.
Then, Conectiva's and WindowMaker's Alfredo Kojima ported apt to rpm-world. They claimed it was difficult, but that rpm provided better granularity. The cross-plataform OpenPKG installer also chose rpm over debs, because of granularity. Apparently, rpms are more flexible. Fact is, deb format demmands too much human intervention, it seems. At least, Debian developers don't seem to get their act together, and I believe there is a direct correlation between their choice of database-dependent software installation and their project getting bogged down. The larger the number of developers, the harder the collective task became. And remember, there's the added social problem that, in Debian, that if you package a little something, you get voting and arguing rights to drive everyone insane until the end of eternity in mailing-lists.
Recently, Conectiva (*) (now Mandriva) developed better algorithms for apt-rpm that are "smarter" (but probabilistic, IIRC - which I don't think is good enough -well, maybe it _is_ good enough). I don't think, however, that anyone has ever conducted a serious investigation on these dependency-solving technologies (although I've read work regarding C libraries) on open-source software, AFAIK. I suspect that would demand substantial mathematical sofistication (applied algebra, lattice theory, algorithmic complexity). Also, the Debian project would have been an excellent testing ground for the development of new automated technologies, like XML description of dependencies (I'm thinking something along the lines of what bioinformatics geeks do), on-line databases of package statistics, etc. Using the web for data about the project, machine-readable data. However, even general statistical studies on Debian productivity would have been interesting (yes, I know there are general descriptive statistics here and there, but there aren't any exploratory statistical studies), but they don't seem to have seen very far ahead. Then, there's the added burden that becoming a Debian developer is needlessly burocratic (and subject to local geopolitical machinations - you have to get along with the local fellows - which, at least for me, has become impossible on ethical grounds - they like to kiss ass to government officials tooo much here in Brazil - I guess they want their piece of the cake, too).
OTOH, the BSDs came up with "let's just use Make", which itself is a tool that solves dependences by recurring the DAG tree. It's so obvious.
So, to sum it up, I think there are more problems with the choice of package installation than meets the eye. (**)
(*) I'm not affiliated to Conectiva nor Mandriva
(**) A little-known Linux distro that does away with packages _and_ the Unix FHS, taking a whole new approach is GoboLinux - you might want to check it out.
Dude, I think you are confusing Debian with the BSD's.
The BSDs have far greater code compatibility in both kernel and userland than Linux distros. Code is shared widely amongst BSD distros. You just don't know much about BSDs. FreeBSD's port system caught on quickly, even on Gentoo (sort of), and NetBSDs pkgsrc even has binaries for Debian. You can even have Linux binary emulation in BSDs. Heck, you can have a FreeBSD emulation in an OpenBSD.
The BSDs used a clever, obvious, scheme for userland: makefiles. Makefiles solve dependencies, because they're a Directed Acyclic Graph. There's this joke that Make is the only Artificial Intelligence program that ever worked.:-)
The makefiles in ports fetch code of the Net and compile them. It fetches the tarball. That scheme is very smart. It uses Unix features, it didn't invent database package managers that have to be kept in sync and that need massive amount of human resources to keep them up-to-date. Like Debian, who proved this scheme doesn't work. This is the lesson from Debian, I believe: automate. Don't rely on engineering humans, like Debian did. Use software.
OpenBSD install is *not* a nightmare. It's regarded as pretty straightforward. You just have to have some attention span to read the FAQ. Can you do that?
Otherwise, it's a smooth install. It's not a Linux install, though, it's different. And, also, they generally assume you will *not* be dual-booting.
Let's dismistify this thing that OpenBSD in an alien OS. It's a rock-solid Unix, secure, peer-verified-code with mechanisms built-in to prevent attacks. It's ports tree is growing.
The "average" open-source person will not be missing a lot on their ports tree. Only if you need unsual software (unusual in terms of the average Unixhead), like some Common Lisp compilers, or cutting-edge programming languages (Alice, Oz, Mercury, etc) you will miss stuff in the ports tree. You can even install Java (you might miss Mono - but probably nobody's given a serious try at compiling Mono on OpenBSD (*)) But this is not your Linux-kid OS that wants a M$ replacement.
Please remember BSD has a long history of Unix development. It doesn't have the money that Linux currently is attracting from the suits, but please take an unbiased view: look at the security record of any BSD and compare with *this year's* Linux kernel exploits (25, IIRC). However, people have different needs (some want Java, some want security, some want performance, others have different different hardware and need portability, others need to work on a supercomputer - whatever), so that has to be taken into account. My point is: all this is Unix. And that's a Good Thing.
(*) A whole different problem, that seems to be growing, is people writing software full of Linuxisms, instead of writing stuff for *UNIX*, in which case it should be portable. This has been a cause of trouble for some programs, for me at least.
Trouble is, bound by democracy, the tyranny of the majority, this will never pass.
It occurs to me that Debian is an interesting case study for modelling social networks. You have this group of people, with this group of rules, and an initial quantity of workload, and an initial work throughput. When the group grows, and so does the workload, after a certain amount of time you get an effect that the group is unable to maintain throughput, because of the rules. It's kind of like modelling ecological systems, I would guess.
Would this be feasible, if you compiled statisitcs for each developer, each rule (packaging rule, license rule, commit rule, bug reports, etc), "time to market"[*], etc? Maybe.
In the end, you might approach a situation of ecological disaster, which is the equivalent of where Debian's at right now, IMHO. Maybe if you alter some parameters, like "drop GPL", the model doesn't evolve to famine (just joking:-)). [**]
I wonder if Debian could be analyzed like that...hmm...Even Debian's failing get to be, in the end, a worthwhile Debian endeavour.
-----
{*] There's always a market, even if you say you're outside the market. Let's not get into Set Theory here, though.
[**] Actually, the GPL is great of you want to write proprietary code, as the dual-licensed products illustrate, e.g., MySQL. The BSD license is a whole different spirit: so what if you take the code and incorporate it? The mother code base is there. But this is another topic.
2. Mandrake: (..) but now you have to pay to get most of the enticing features included. Three CDs for free version, and six CDs for paid version.
Yeah, that's right, you're paying for their job. You can get the sources. Do you want everything free as in beer? F/OSS was never/that/.
Although I don't use Mandrake, last month I looked at it, and they were charging something like $22/year (or was it $122 ?) so you could just sit back on your chair and hit the update button. Is that tooooo much?
This mentality that Free Software is beer sucks. You can always patch your systems by hand, you know...If you want somebody to manage all those changes for you, you pay. It's a reasonable model, it keeps people working and the software flowing.
You're right... I guess Debian's problems are more serious than is usually assumed. Maybe it's fair to say they're dying. No joke. In critical state, at least. I guess everybody was just so giddy-up with Ubuntu, nobody ever paused to give it much thought. I personally don't use Ubuntu (I changed Debian for OpenBSD, the only true Free distro out there (TM), I shit you not:-)), but I can see why people got elated.
Sad, but I guess it all started with the wrong model for package management, and then the wrong social model. You end up in tangles.
Slashdot Mirror
Yeah, whatever. You can't trust Java for anything remotely numeric, it's broken, it's a fact. Anyone who's read professor Kahan's (Berkeley) How JAVA's Floating-Point Hurts Everyone Everywhere papers, and followed the issue for a little time will run like the devil from Java... ;-)
I mean, modelling disease involves differential equations. You have to be crazy to use Java. C is much more trustworthy in that respect.
In fact, this knowledge should be widespread.
It's sad to see so many people take for granted that something a big company did is flawless.
Yes, it will, because the kid has learned the value of F/OSS software.
Now, if only OO.org wasn't beta software...
Man, I had the same problem! (see my post somewhere else). I wrote a paper and got whipped by OO.org bugs! Lost a whole point in my grade for that.
Miracle you weren't modded as "flamebait" by the OO.org fanboy crowd.
Yeah, I mean what's up with all this intellectual dishonesty that some are displaying here, saying there aren't any compatibility issues, that OO.org is just great? .doc format, I complain to them, explaining there are over 10 operating systems I could install on my computer right now that have e-mail, browser, etc. Only one of them has MS Word. And then I say "could you please be so kind as to generate the file in a truly universal format?"
If you don't live in a nice smug LaTeX bubble (that is, if you don't work in the Math department), you _know_ the M$ Word drones will come after you, eventually, with an incompatible file.
And here is half-ass solution: whenever people send stuff in
Good question. Here's my experience, which is bound to be modded as flamebait by /. OpenOffice fanboys: .doc format, don't bother posting your opinion, thank you very much.
I've stretched OpenOffice more than your average zealot, choosing it to write a full report, as I had no M$ system available and needed to interoperate with the general LaTeX-phobic population. It was a disaster, and this was when it was considered "stable" and not beta. In fact, it was beta software. It had a bug that, misteriously, corrupted all page numbering. And I couldn't get the numbering correct again, ever, having to deliver it like that, apologizing for a "bug in the software." Of course, that penalized me.
Also, inserting a large amount of color images almost brought it to grind...I was definitely pissed off...And there wasn't any time to be filling out bug reports.
Recently, I've tested OpenOffice 1.1.3. It had such basic bugs still, like (for instance) I couldn't write "São Paulo" (I need the til in my native language - Portuguese). Frankly, I don't care what people say, OpenOffice is below standard. You can hype it all you want, you can go bezerk with open source zealotry (*), OpenOffice is beta software, period. Now, please, if all you do is write 3 pages and save in
Don't get me wrong, I love the idea of a Libre Software office package, but this isn't it. I'm hoping AbiWord will get there. I builds everywhere (unlike Java), and it has plug-ins, so I'm hoping it'll develop to be an interesting thing.
(*) Now, I'm not only pissed off with the bugs, I'm also pissed off with the Java dependency. This fixation on Java should develop in a C# (Mono) fixation because, frankly, I understand the point of avoiding C++, and Java is a no go in BSD (because it's not libre software).
If you don't want it, don't compile it i
0 04/10/e06 94abs.htm
Sure, that's the default answer. But, I don't know much about the Linux kernel, so allow me this little speculation:
How is the kernel affected by desktop requirements? How does enterprise use vs. game use shape issues like memory, and threading? Are there any issues vis-à-vis these differences? That's an interesting question, in which case, if there are, would there be an impact, since there is fundamental design interdependece between them? Here's an interesting paper by MIT (and the abstract):
Maintainability of the Linux Kernel
Schach, Jin, Wright, Heller & Offutt
"We have examined 365 versions of Linux. For every version, we counted the number of instances of common (global) coupling between each of the 17 kernel modules and all the other modules in that version of Linux. We found that the number of instances of common coupling grows exponentially with version number. This result is significant at the 99.99% level, and no additional variables are needed to explain this increase. We conclude that, unless Linux is restructured with a bare minimum of common coupling, the dependencies induced by common coupling will, at some future date, make Linux exceedingly hard to maintain without inducing regression faults."
Also:
Categorization of Common Coupling and Its Application to the Maintainability of the Linux Kernel, by Liguo Yu, Stephen R. Schach, Kai Chen, Jeff Offutt, IEEE Computer Society
http://csdl.computer.org/comp/trans/ts/2
"Data coupling between modules, especially common coupling, has long been considered a source of concern in software design, but the issue is somewhat more complicated for products that are comprised of kernel modules together with optional nonkernel modules. This paper presents a refined categorization of common coupling based on definitions and uses between kernel and nonkernel modules and applies the categorization to a case study. Common coupling is usually avoided when possible because of the potential for introducing risky dependencies among software modules. The relative risk of these dependencies is strongly related to the specific definition-use relationships. In a previous paper, we presented results from a longitudinal analysis of multiple versions of the open-source operating system Linux. This paper applies the new common coupling categorization to version 2.4.20 of Linux, counting the number of instances of common coupling between each of the 26 kernel modules and all the other nonkernel modules. We also categorize each coupling in terms of the definition-use relationships. Results show that the Linux kernel contains a large number of common couplings of all types, raising a concern about the long-term maintainability of Linux."
Fuck that: don't give developing countries $100 computers, give them the $1000 ones that are being wasted on the so called developed countries - hey they're already developed, so they shouldn't need them, right?
/. post pretty amazing, and found them to be in sharp contrast with what is being done in my own country. :-)
Although I empathize with your troubles teaching spoiled kids, I have to say I found the technologies mentioned in this
I live in Brazil and just today I read in the morning newspaper about PC Conectado, which is supposed to be Brazil's answer to the problem of computer technology for the masses, and I found those technologies (the $100,00 laptop, the simputer, and the loband thing) to be quite an advance in terms empowering technology, concepts, and efforts to bring technology to the people.
The PC Conectado, in contrast, will sell for R$1,400 (that's US$ 535 at today's exchange rate). The high-fallutin' high-priests of Brazil's Free Software community are ecstatic because it'll come loaded with F/OSS software. That's good, but Brazil's minimum wage is R$ 260,00 ( = US$ 99 ), so PC Conectado is way expensive. In fact, it appears to be a stripped-down PC, and costing around what a stripped-down PC costs. It's not as cheap as it ought to be. Wal-Mart, the cheapo department store in USA, has 'puters for less (I've checked here today.)
So, in contrasting these 3 projects with the PC Conectado, I found nice food-for-thought. Here are my 2 cents futurology and thoughts:
1) While Free Software is nice, it may not be what people want, because it might not correspond to what people expect. It might just be that when people learn they can't play Windows warez games or office software in PC Conectado, they will uninstall GNU/Linux. Currently, for medium wage jobs in Brazil, the job market demmands some expertise in Windows software, and some might want to buy a PC to get that expertise and hone skills in Excel or whatever. If your hardware allows shifting to Windows, will they stick to GNU/Linux? I don't think so...
2) What is really needed is cheap hardware. You can't cheat like PC Conectado. You need $ 100 laptops. Cheap means cheap.
3) If you have custom hardware, there is no "turning back" to proprietary software.
4) Research groups must focus on new concepts. Old concepts will not only cost more, they might backfire. When you take low income populations, their whole model of what's "top" might be what is the dominant technology (and we know that's not the best choice).
5) Internet access is not a luxury. It's as much of a luxury as library access is a luxury. "The net is the computer." (TM Sun Microsystems)
6) Hand in hand with this custom new hardware an net technologies, we need to teach children what computer programming is.Developing countries do *not* need government-subsidized programs to teach people to use Microsoft software. In the long run, this will empower developing countries and create a virtuous circle.
So, IMHO, "the $1000 ones [computers] that are being wasted on the so called developed countries" isn't gonna cut it. I really think governments of developing world must foster research groups with innovative ideas.
McVoy contributed more than $500 000 worth of software to the osdl
I am curious as to how one gets at such a figure (seriously). Does he count all the developers using the FAIB (free-as-in-beer) version and then adds that to BK developer time? Or does he also calculate "if these guys were not supporting BK, they would develop for non-FAIB BK"?
Here's the way Linus views the difference between Samba and BK:
Anobody that compares that to Open Office (or even samba, which Tridge did write) is an idiot. Open office and samba are constructive projects that actually do something useful,and are technically advanced quite regardless of the fact that they can interoperate with the competition. They look at the file data because they then _use_ it (...)" (I bolded it).
Just so one has more context, before he said that, he also said: "Tridge could have done something constructive: he could have written the best damn SCM on the planet, and believed that open source generates better things, and competed against BitKeeper that way. (...) But that's not what Tridge did. He didn't write a "better SCM than BK". He didn't even try - it wasn't his goal. He just wanted to see what the protocols and data was, without actually producing any replacement for the (inevitable) problems he caused and knew about."
You can read the whole post here
Apt-get, AFAICT, is well designed
You know, when he/she said that, I wondered if he/she ever read dpkg's source code... A decade later and Debian developer don't even have decent documentation of a central piece in their distro. I
what exactly is the issue for which the Debian project's choice of packaging technology is a problem?
Look for a thread (not mine) called "Binary Compatibility Is Hard(TM)" for interesting insights. I've elaborated some more in other threads, but they weren't moderated up much.
You have to realize dpkg is very old. It's code is a mess, it's undocumented. Anyone trying to improve that would probably get ignored on religious basis (in fact, Alfredo Kojima of WindowMaker/Conectiva fame did that with apt-rpm). Debian's packaging mechanism involves quite a bit of human handwork. This bogged down the project. I believe it was one of the main factors. Look for an AC thread called "Metcalfe's Law", too.
is the issue for which the manner in which Debian is handled as a social project is a problem?
I believe it's a problem because, in Debian, every "developer" gets to vote and thereby steer the project in this or that direction. I think even "developer" is a misnomer, because a lot of those guys are just maintainers. In FreeBSD land they would be called "commiters." A lot of them are not people who can really hack deep things like protocols and kernel. Compare them with BSD developers and you will see what I mean. Debian is too much of a democracy, instead of a meritocracy.
So in the end, you get this situation where the organization slows to a halt. This happened. For real. Look at it.
Also, let me just remind you that the winner of the DPL title this year also thinks there are problems with Debian's social organization and constitution.
The Debian project team seems committed to having 'stable' mean stable, 'testing' mean not stable
Please, get it over it. Use a BSD for an experience of "stable" and "up-to-date" (I was not always a BSD zealot, I used to be a Debian diehard).
That's a 5 right there!
One of the best pieces of all.
Shameless plug: somewhere else here I've expressed my view that maybe the fundamental problem with Debian - possibly what originates all others - is their packaging technology. They treat it like a religion, even though it was written, IIRC, almost a decade ago.
You have achieved great insight with your piece. In fact, it's so obvious that one wonders why so many miss these simple facts.
Also read an AC post called "Metcalfe's law", which wasn't justly moderated, about the growth of Debian packages being N^2.
PS: You don't always install from source on BSDs, you can install packages (for things that are too big, like KDE, etc). Also, might wanna read up on how GoboLinux approaches these issue, and also the pkgsrc documentation (see here for some insights on installing "incompatible" stuff).
Ubuntu wants to work with debian, to make a better debian, but the goals of Ubuntu and Debian are different. debian aims at a pure FOSS os, while ubuntu aims at a viable commercial desktop linux distro.A viable commercial Linux require a lot of 'free as in beer' software to run properly (...) Even though i have sarge, i installed both of the above (...) because I needed (...).
See, all Debian fanboys install non-free software. just read Planet Debian.
Let me inaugurate two new concepts: free-enough-for-me free software
and really-free free software . Linux is FEFM, because more and more binaries from companies get in the kernel. Once that trend starts, it doesn't stop. OpenBSD is RFFS, because Theo de Raadt will spit on your face if you even propose to have binaries, and will drop support for your dear hardware. That is, he believes in the market economy: "Oh, don't wanna contribute so we can write drivers? Fine, we'll go buy from someone else." See, you can use the market to your favor. Linus fanboys must learn that.
Call me a zealot, and a troll, I don't care. I tell the truth. Once those little binaries creep in, once you give in to the suits, you're fucked. It's not free software anymore. They have no respect. It's all money to them. Freedom and ethics are better, but some just don't think so. So stop this Debian fanboy hipocrisy, all this jive about "a pure OS."
Debian Developers, they spend years trying to get their software to work on archs that no one ever uses any more
It always seems like they're incesing their glorified self when they say that. However, if you judge them by an objective comparison, you just have to compare them with NetBSD, which supports far more architectures and yet, are able to maintain their distro up-to-date. Plus, they don't only hack at userland software, but also on kernel and protocols, while Debian just does security and packaging. So, by all accounts, Debian needs to stop justifying their mistakes with shitty excuses.
Troll. Right there.
Mod that up, it's insightful! And, IIRC, testing is about 15000.
As a simple example, a package might be excluded from Debian 'testing' due to a build failure on any of the 11 architectures supported by Debian 'sarge', but it is still suitable for Ubuntu if it builds and works on only three of them. A package will also be prevented from entering Debian 'testing' if it has release-critical bugs according to Debian criteria, but a bug which is release-critical for Debian may not be as important for Ubuntu.
I believe you gave a crystal-clear explanation with one of Debian's deepest problems. Why must all the packages in all those architectures be in sync? It's artificial. If it doesn't work, it doesn't work. Until it does. Period. Put a machine-readable info somewhere about this status, and comparison charts on the web. Tough luck, no developer resources/interest/time enough, and keep the dharma wheel moving.
I would like to see the leadership of the two organizations get together, discuss the idea, and hopefully agree that this is a good way to work together. The leadership can then promote co-maintainership as a 'best practice' within their own organizations, inform the userbase (i.e. get it mentioned on slashdot), PLUS appoint an interoperability liason.
Seriously, don't you think all that is up to Debian? I think Ubuntu may or may not agree, but I don't see them having a problem. You got yourseleves into a quagmire. You must do something about it. Debian used to have a lot of respect, but you lost a lot of it...Stop acting like Ubuntu is the problem. Ubuntu is the solution. For most of ex-Debian users.
I don't mean to be rude, but you gotta develop focus on the issue. The problem is Debian and how it's handled as a social project, and its choice of software packaging technology.
RPM was poorly designed from the start, and was probably designed from the start as a tool for vendor lock-in. Apt-get, AFAICT, is well designed.
I used to think apt-get was great, and that rpm sucked. Until I looked at dpkg's source code, and found undocumented funtions like void ohshit. Come to think of it, it's still undocumented.
Then, Conectiva's and WindowMaker's Alfredo Kojima ported apt to rpm-world. They claimed it was difficult, but that rpm provided better granularity. The cross-plataform OpenPKG installer also chose rpm over debs, because of granularity. Apparently, rpms are more flexible. Fact is, deb format demmands too much human intervention, it seems. At least, Debian developers don't seem to get their act together, and I believe there is a direct correlation between their choice of database-dependent software installation and their project getting bogged down. The larger the number of developers, the harder the collective task became. And remember, there's the added social problem that, in Debian, that if you package a little something, you get voting and arguing rights to drive everyone insane until the end of eternity in mailing-lists.
Recently, Conectiva (*) (now Mandriva) developed better algorithms for apt-rpm that are "smarter" (but probabilistic, IIRC - which I don't think is good enough -well, maybe it _is_ good enough). I don't think, however, that anyone has ever conducted a serious investigation on these dependency-solving technologies (although I've read work regarding C libraries) on open-source software, AFAIK. I suspect that would demand substantial mathematical sofistication (applied algebra, lattice theory, algorithmic complexity). Also, the Debian project would have been an excellent testing ground for the development of new automated technologies, like XML description of dependencies (I'm thinking something along the lines of what bioinformatics geeks do), on-line databases of package statistics, etc. Using the web for data about the project, machine-readable data. However, even general statistical studies on Debian productivity would have been interesting (yes, I know there are general descriptive statistics here and there, but there aren't any exploratory statistical studies), but they don't seem to have seen very far ahead. Then, there's the added burden that becoming a Debian developer is needlessly burocratic (and subject to local geopolitical machinations - you have to get along with the local fellows - which, at least for me, has become impossible on ethical grounds - they like to kiss ass to government officials tooo much here in Brazil - I guess they want their piece of the cake, too).
OTOH, the BSDs came up with "let's just use Make", which itself is a tool that solves dependences by recurring the DAG tree. It's so obvious.
So, to sum it up, I think there are more problems with the choice of package installation than meets the eye. (**)
(*) I'm not affiliated to Conectiva nor Mandriva
(**) A little-known Linux distro that does away with packages _and_ the Unix FHS, taking a whole new approach is GoboLinux - you might want to check it out.
It means, as somebody pointed out above regarding Ubuntu, that it needs to evolve and loose bodily hair, developing itself into a more naked human.
Dude, I think you are confusing Debian with the BSD's.
:-)
The BSDs have far greater code compatibility in both kernel and userland than Linux distros. Code is shared widely amongst BSD distros. You just don't know much about BSDs. FreeBSD's port system caught on quickly, even on Gentoo (sort of), and NetBSDs pkgsrc even has binaries for Debian. You can even have Linux binary emulation in BSDs. Heck, you can have a FreeBSD emulation in an OpenBSD.
The BSDs used a clever, obvious, scheme for userland: makefiles. Makefiles solve dependencies, because they're a Directed Acyclic Graph. There's this joke that Make is the only Artificial Intelligence program that ever worked.
The makefiles in ports fetch code of the Net and compile them. It fetches the tarball. That scheme is very smart. It uses Unix features, it didn't invent database package managers that have to be kept in sync and that need massive amount of human resources to keep them up-to-date. Like Debian, who proved this scheme doesn't work. This is the lesson from Debian, I believe: automate. Don't rely on engineering humans, like Debian did. Use software.
OpenBSD install is *not* a nightmare. It's regarded as pretty straightforward. You just have to have some attention span to read the FAQ. Can you do that?
Otherwise, it's a smooth install. It's not a Linux install, though, it's different. And, also, they generally assume you will *not* be dual-booting.
Let's dismistify this thing that OpenBSD in an alien OS. It's a rock-solid Unix, secure, peer-verified-code with mechanisms built-in to prevent attacks. It's ports tree is growing.
The "average" open-source person will not be missing a lot on their ports tree. Only if you need unsual software (unusual in terms of the average Unixhead), like some Common Lisp compilers, or cutting-edge programming languages (Alice, Oz, Mercury, etc) you will miss stuff in the ports tree. You can even install Java (you might miss Mono - but probably nobody's given a serious try at compiling Mono on OpenBSD (*)) But this is not your Linux-kid OS that wants a M$ replacement.
Please remember BSD has a long history of Unix development. It doesn't have the money that Linux currently is attracting from the suits, but please take an unbiased view: look at the security record of any BSD and compare with *this year's* Linux kernel exploits (25, IIRC). However, people have different needs (some want Java, some want security, some want performance, others have different different hardware and need portability, others need to work on a supercomputer - whatever), so that has to be taken into account. My point is: all this is Unix. And that's a Good Thing.
(*) A whole different problem, that seems to be growing, is people writing software full of Linuxisms, instead of writing stuff for *UNIX*, in which case it should be portable. This has been a cause of trouble for some programs, for me at least.
Trouble is, bound by democracy, the tyranny of the majority, this will never pass.
:-)). [**]
It occurs to me that Debian is an interesting case study for modelling social networks. You have this group of people, with this group of rules, and an initial quantity of workload, and an initial work throughput. When the group grows, and so does the workload, after a certain amount of time you get an effect that the group is unable to maintain throughput, because of the rules. It's kind of like modelling ecological systems, I would guess.
Would this be feasible, if you compiled statisitcs for each developer, each rule (packaging rule, license rule, commit rule, bug reports, etc), "time to market"[*], etc? Maybe.
In the end, you might approach a situation of ecological disaster, which is the equivalent of where Debian's at right now, IMHO. Maybe if you alter some parameters, like "drop GPL", the model doesn't evolve to famine (just joking
I wonder if Debian could be analyzed like that...hmm...Even Debian's failing get to be, in the end, a worthwhile Debian endeavour.
-----
{*] There's always a market, even if you say you're outside the market. Let's not get into Set Theory here, though.
[**] Actually, the GPL is great of you want to write proprietary code, as the dual-licensed products illustrate, e.g., MySQL. The BSD license is a whole different spirit: so what if you take the code and incorporate it? The mother code base is there. But this is another topic.
2. Mandrake: (..) but now you have to pay to get most of the enticing features included. Three CDs for free version, and six CDs for paid version.
/that/.
Yeah, that's right, you're paying for their job. You can get the sources. Do you want everything free as in beer? F/OSS was never
Although I don't use Mandrake, last month I looked at it, and they were charging something like $22/year (or was it $122 ?) so you could just sit back on your chair and hit the update button. Is that tooooo much?
This mentality that Free Software is beer sucks. You can always patch your systems by hand, you know...If you want somebody to manage all those changes for you, you pay. It's a reasonable model, it keeps people working and the software flowing.
You're right... :-)), but I can see why people got elated.
I guess Debian's problems are more serious than is usually assumed. Maybe it's fair to say they're dying. No joke. In critical state, at least. I guess everybody was just so giddy-up with Ubuntu, nobody ever paused to give it much thought. I personally don't use Ubuntu (I changed Debian for OpenBSD, the only true Free distro out there (TM), I shit you not
Sad, but I guess it all started with the wrong model for package management, and then the wrong social model. You end up in tangles.
Somebody mod the parent up!!!