And in related news, the United States Patent and Trademark Office is being sued by SCO due to their patent on the process of reviewing and approving patents;-)
That's old news. The lawsuit was dismissed, on the basis that the patent covers "reviewing and approving" patents, and USPTO doesn't do any reviewing of patents prior to issuing them.
They filed for chapter 11 this year. That means they have been asking for donations through the club for two years before they started having real financial troubles.
That's my point. Simply asking for donations wasn't enough to keep them out of bankruptcy. MandrakeSoft only turned around after telling everyone that they were about to go out of business.
it shows that an appropriate business model can help Linux companies greatly
I don't think that MandrakeSoft's business model really scales very well. 1. Tell everyone that you're about to go out of business. 2. Ask for donations. 3. PROFIT! may have worked so far, but it's self-limiting -- as soon as you start to PROFIT!, it becomes hard to claim that you're about to go out of business.
Well, most of what people do on desktops isn't kernel-intensive. But you're right; this is a consideration, and I'll be raising the issue after 5.2 is released.
There's two issues here; first, sysinstall needs to be updated to ask the user which kernel is desired -- and sysinstall is a minefield which most people want to avoid at all costs. Second, shipping two kernels eats up disk space, and the ISO is getting rather crowded already.
But yes, I imagine that shipping two kernels is the direction things are going to go -- at least assuming that nobody comes up with a faster method of locking on SMP platforms.
Secondly, it takes years to learn how to program WELL in a complex language like C++.
No. It takes years to learn how to program well. Once you know how to program well, picking up a new language shouldn't take more than a few weeks, except in the most baroque cases (INTERCAL, BrainF***, etc).
Pre-5.2 RELEASEs ship with uniprocessor kernels. If you want SMP support, you have to recompile.
5.2, and future RELEASEs, will ship with SMP kernels. Due to the added overhead of kernel locking, this cuts kernel performance by about 20%. If you've got a uniprocessor machine, and you're doing kernel-intensive work, youll probably want to recompile.
"With open source, there is a lot of daylight. A lot of people looking at the code. You don't really go around and steal things."
With open source, lots of people are looking at the code. If there's a bug, people will find it (well, that's the theory, at least).
I'm not convinced that lots of people are looking at where the code came from. To take FreeBSD Update as an example, I've engaged in lots of lengthy discussions about technical issues, but nobody has ever asked "did you write this code yourself?"
Also, if the changes to program source code are fairly small, it can make more sense to incorporate them in the main source tree so that they can more easily stay up to date - rather than having a dozen patch sets maintained by disparate people.
Sure; there's nothing to say that you can't look at the patches people are distributing. But there's a balance -- it doesn't make sense to include lots of #ifdef AIX code when 99.99% of users don't run AIX.
if you want your app to run on AIX 4.x do you really expect IBM to create and maintain the port?
Exactly -- *if* I want my app to run on AIX. Is there even anyone on AIX who would want to use my app? Do I have access to an AIX box where I can test my app? Let whoever wants AIX support provide it themselves.
Would you suggest that KDE, for example, should drop Solaris and FreeBSD support and concern itself only with running on Linux?
Large projects, like KDE, Gnome, Apache, etc. are different. As you point out, they have core developers who use different platforms; it makes sense to support those. Most projects, however, are small, have 1-3 developers, and all the developer(s) use the same one or two operating systems.
It's tracking the plows. The government may not have the right to track where people go, but surely it has a right to track where government property goes.
This is nothing more than employees getting irate about losing their unofficial extended coffee breaks.
I'm slightly curious why you used a program you admit wasn't really meant to be portable as an example of a better approach to portability
That's my point. I didn't think about portability at all while I was writing BSDiff, yet with a couple patches, it compiles and runs properly on a completely different platform.
But I was suggesting you write a POSIX makefile, with which people can use whatever make utility they prefer. Isn't that a laudable aim?
Well... yes, but POSIX make is missing some rather important features..if/.else/.endif, for example, and.include.
Unfortunately I'm looking to use it on Cygwin
You could pull the patches out of Gentoo's tree and try those; I don't know if that's enough. Does Cygwin support fork()ing?
Ah, an interesting example. You see, I recently tried to evaluate your BSDiff program. Not only could I not build it, I couldn't even figure out how to modify it to make it build - because you haven't even tried to write portable code.
In that particular case, I wrote the program for a specific purpose -- FreeBSD Update -- and was surprised by how many people wanted to use it for other purposes. So no, I wasn't really trying to write portable code. (On the other hand, GNU make is five times as large as BSD make, and is distributed under a much more restrictive license, so I don't think supporting GNU make is necessarily a laudable aim.)
In the mean time, if you're looking to use BSDiff on linux, you could always use Gentoo's port.
Editing Makefiles (or Imakefiles if you are lucky) is often like "reading core dumps", as someone put it.
Makefiles are often poorly written. In particular, people very often fail to use.include directives properly.
If you want to see well-written Makefiles, look in the BSD source tree. Taking one at random, here's FreeBSD's src/usr.sbin/edquota/Makefile: # @(#)Makefile 8.1 (Berkeley) 6/6/93 # $FreeBSD:/repoman/r/ncvs/src/usr.sbin/edquota/Makefile,v 1.8 2003/04/04 17:49:13 obrien Exp $
Rather than attempting to include support for every architecture via autoconf, I think the BSD ports approach is far superior: Write code once, and have people put together their own sets of patches, makefile wrappers, et cetera to fit their own architecture.
For example, I wrote my binary patching tool on FreeBSD, but I don't recommend that people (even on FreeBSD) build it directly from the source tarball; instead, I advise people to use the ports tree, since that puts BSDiff into FreeBSD's packaging system. If someone running Gentoo wants to use BSDiff, they can install it from portage, which adds workarounds for gmake and linux breakage.
Most developers only have access to a couple platforms for testing their code. Rather than doing a poor job of supporting every platform, it makes much more sense to support one platform directly, and allow other people to step in and provide the necessary patches and packaging to support other platforms.
$5/month might not seem like much, but... if I was getting that much from everyone using the binary updates I'm building for FreeBSD, I'd be very very happy.
IMHO, anyone who thinks it costs anywhere near that much to provide binary updates is still thinking in VC-inflated, height-of-the-bubble dollars.
The x86 architecture has had a bound-checking instruction for a long time -- since the 8088, I think. But nobody used it, so it has long since been relegated to being implemented in microcode, at a cost of about a dozen cycles per call.
Quite the opposite, actually. "Canadian" is what many illegal and unlicensed pharmacies are calling themselves -- in many cases, so-called "Canadian pharmacies" consist of a website run off a server in.us, and a bunch of people in India shipping the drugs. The Canadian government isn't happy about the country being given a bad name, but since these organizations don't conduct any business in Canada, it's hard to take action against them.
Slashdot Mirror
And in related news, the United States Patent and Trademark Office is being sued by SCO due to their patent on the process of reviewing and approving patents ;-)
That's old news. The lawsuit was dismissed, on the basis that the patent covers "reviewing and approving" patents, and USPTO doesn't do any reviewing of patents prior to issuing them.
Hmm, isn't 0.85" the drive thickness? As in, the height of the platter stack?
No. 0.85" is the platter diameter.
Whenever I read about hard disks in a cell phone I always wonder about the gyroscope effect making the phone hard to manage.
I imagine that, for power saving purposes, the hard drive would spin slowly, and be spun down most of the time anyway.
This raises another question, however: When the mobile phone starts its hard drive, would the phone start to spin?
They filed for chapter 11 this year. That means they have been asking for donations through the club for two years before they started having real financial troubles.
That's my point. Simply asking for donations wasn't enough to keep them out of bankruptcy. MandrakeSoft only turned around after telling everyone that they were about to go out of business.
it shows that an appropriate business model can help Linux companies greatly
I don't think that MandrakeSoft's business model really scales very well.
1. Tell everyone that you're about to go out of business.
2. Ask for donations.
3. PROFIT!
may have worked so far, but it's self-limiting -- as soon as you start to PROFIT!, it becomes hard to claim that you're about to go out of business.
As we all know, open source code is transparent; it's all out there for everyone to see.
So why did it take four years to notice this?
What do you think dogs and other wild animals do with their stillborn? They eat them of course!
This doesn't just apply to the stillborn.
Well, most of what people do on desktops isn't kernel-intensive. But you're right; this is a consideration, and I'll be raising the issue after 5.2 is released.
There's two issues here; first, sysinstall needs to be updated to ask the user which kernel is desired -- and sysinstall is a minefield which most people want to avoid at all costs. Second, shipping two kernels eats up disk space, and the ISO is getting rather crowded already.
But yes, I imagine that shipping two kernels is the direction things are going to go -- at least assuming that nobody comes up with a faster method of locking on SMP platforms.
Secondly, it takes years to learn how to program WELL in a complex language like C++.
No. It takes years to learn how to program well. Once you know how to program well, picking up a new language shouldn't take more than a few weeks, except in the most baroque cases (INTERCAL, BrainF***, etc).
You misunderstand. Defense contractors make far more money in times of war than in times of peace.
You misunderstand. He's saying that he knows C, C++, PHP, perl, ++C, and lrep.
Somehow, I don't think many defense contractors would want to hire someone who intends to win the Nobel Peace prize.
Pre-5.2 RELEASEs ship with uniprocessor kernels. If you want SMP support, you have to recompile.
5.2, and future RELEASEs, will ship with SMP kernels. Due to the added overhead of kernel locking, this cuts kernel performance by about 20%. If you've got a uniprocessor machine, and you're doing kernel-intensive work, youll probably want to recompile.
"With open source, there is a lot of daylight. A lot of people looking at the code. You don't really go around and steal things."
With open source, lots of people are looking at the code. If there's a bug, people will find it (well, that's the theory, at least).
I'm not convinced that lots of people are looking at where the code came from. To take FreeBSD Update as an example, I've engaged in lots of lengthy discussions about technical issues, but nobody has ever asked "did you write this code yourself?"
Also, if the changes to program source code are fairly small, it can make more sense to incorporate them in the main source tree so that they can more easily stay up to date - rather than having a dozen patch sets maintained by disparate people.
Sure; there's nothing to say that you can't look at the patches people are distributing. But there's a balance -- it doesn't make sense to include lots of #ifdef AIX code when 99.99% of users don't run AIX.
if you want your app to run on AIX 4.x do you really expect IBM to create and maintain the port?
Exactly -- *if* I want my app to run on AIX. Is there even anyone on AIX who would want to use my app? Do I have access to an AIX box where I can test my app? Let whoever wants AIX support provide it themselves.
Would you suggest that KDE, for example, should drop Solaris and FreeBSD support and concern itself only with running on Linux?
Large projects, like KDE, Gnome, Apache, etc. are different. As you point out, they have core developers who use different platforms; it makes sense to support those. Most projects, however, are small, have 1-3 developers, and all the developer(s) use the same one or two operating systems.
It's tracking the plows. The government may not have the right to track where people go, but surely it has a right to track where government property goes.
This is nothing more than employees getting irate about losing their unofficial extended coffee breaks.
I'm slightly curious why you used a program you admit wasn't really meant to be portable as an example of a better approach to portability
.if/.else/.endif, for example, and .include.
That's my point. I didn't think about portability at all while I was writing BSDiff, yet with a couple patches, it compiles and runs properly on a completely different platform.
But I was suggesting you write a POSIX makefile, with which people can use whatever make utility they prefer. Isn't that a laudable aim?
Well... yes, but POSIX make is missing some rather important features.
Unfortunately I'm looking to use it on Cygwin
You could pull the patches out of Gentoo's tree and try those; I don't know if that's enough. Does Cygwin support fork()ing?
Ah, an interesting example. You see, I recently tried to evaluate your BSDiff program. Not only could I not build it, I couldn't even figure out how to modify it to make it build - because you haven't even tried to write portable code.
In that particular case, I wrote the program for a specific purpose -- FreeBSD Update -- and was surprised by how many people wanted to use it for other purposes. So no, I wasn't really trying to write portable code. (On the other hand, GNU make is five times as large as BSD make, and is distributed under a much more restrictive license, so I don't think supporting GNU make is necessarily a laudable aim.)
In the mean time, if you're looking to use BSDiff on linux, you could always use Gentoo's port.
Editing Makefiles (or Imakefiles if you are lucky) is often like "reading core dumps", as someone put it.
.include directives properly.
/repoman/r/ncvs/src/usr.sbin/edquota/Makefile,v 1.8 2003/04/04 17:49:13 obrien Exp $
.include <bsd.prog.mk>
Makefiles are often poorly written. In particular, people very often fail to use
If you want to see well-written Makefiles, look in the BSD source tree. Taking one at random, here's FreeBSD's src/usr.sbin/edquota/Makefile:
# @(#)Makefile 8.1 (Berkeley) 6/6/93
# $FreeBSD:
PROG= edquota
MAN= edquota.8
WARNS?= 4
Rather than attempting to include support for every architecture via autoconf, I think the BSD ports approach is far superior: Write code once, and have people put together their own sets of patches, makefile wrappers, et cetera to fit their own architecture.
For example, I wrote my binary patching tool on FreeBSD, but I don't recommend that people (even on FreeBSD) build it directly from the source tarball; instead, I advise people to use the ports tree, since that puts BSDiff into FreeBSD's packaging system. If someone running Gentoo wants to use BSDiff, they can install it from portage, which adds workarounds for gmake and linux breakage.
Most developers only have access to a couple platforms for testing their code. Rather than doing a poor job of supporting every platform, it makes much more sense to support one platform directly, and allow other people to step in and provide the necessary patches and packaging to support other platforms.
$5/month might not seem like much, but... if I was getting that much from everyone using the binary updates I'm building for FreeBSD, I'd be very very happy.
IMHO, anyone who thinks it costs anywhere near that much to provide binary updates is still thinking in VC-inflated, height-of-the-bubble dollars.
I don't have a phone number; I can make outgoing calls from my room via a calling card, but I can't get incoming calls.
If you want to contact me, send me an email.
The x86 architecture has had a bound-checking instruction for a long time -- since the 8088, I think. But nobody used it, so it has long since been relegated to being implemented in microcode, at a cost of about a dozen cycles per call.
No AdWords, but a search for "goatse" yields the following helpful hint:
... > Scientology
Category: Society > Religion and Spirituality >
Quite the opposite, actually. "Canadian" is what many illegal and unlicensed pharmacies are calling themselves -- in many cases, so-called "Canadian pharmacies" consist of a website run off a server in .us, and a bunch of people in India shipping the drugs. The Canadian government isn't happy about the country being given a bad name, but since these organizations don't conduct any business in Canada, it's hard to take action against them.