My favourite Windows related one was so good, I took
a screenshot
to preserve it for posterity. This was using a
Citrix-like multi-user NT system from my Sparc.
I've had to -- echo * works well enough, sometimes. Some Linux install disks give you a shell, but few utilities other than mount, mknod, cat, etc. Now, if they gave us ed I wouldn't have to "cat >>/mnt/etc/fstab" and the like.
For probably the ultimate description of
recovering from a
screwed system without access to
the normal tools, see
Al Viro's inhuman heroics
here.
Some people have *silent* ringers and *must* be on call at all times. These people could no longer see a movie if cell phones are disabled.
*No one* is on call 24x7x365. Well, technically I
am, but if I go the the cinema, I turn my mobile
off, and work will have to wait. Others can do
the same. It's a poor reflection on our times
that people think that others can be called any
time, day or night. In reality, there's very little
that can't wait until the following morning.
3. People's cell phones are going off.
Build a Faraday cage over the building before you go in.
Don't know whether you were serious or not, but
some UK cinemas have proposed actually doing this.
I'm not aware of any that have implemented
it yet, but I'm holding out hope...
Maybe Big Blue actually learned a lesson from their DeathStar line of drives.
Actually, IBM make some of the most reliable drives
I've ever used. Yes, they had a very high profile
failure on one particular range of IDE drives,
but I've never had any problems with their SCSI
disks.
I think that record companies distributed Heavy Metal bands on vinyl far longer than any other genre because the improved quality of CDs just didn't make any discernable difference to either the listeners or to the music.
Sigh. If you actually listened to heavy metal,
you'd realise that the quality of both musicianship
and recording is significantly
higher than mainstream music, and so it's a genre
that benefits more from an improved
quality format like CDs. Sure, there's a lot of
heavy metal that doesn't benefit, but then
that's true of every genre (c.f. Sturgeon's Law). Stereotypes may be convenient
for some, but as in this case, they're
frequently wrong.
why not add to blender3d? Why waste resources competing with an opensource project?
Because while Blender may be well endowed with
features, its user interface sucks. Really, really
sucks. Moonlight 3D (and I admit, I haven't used
it in years) had a much better UI.
To rework the blender UI would take a lot
of work, almost a complete rewrite. Besides, as
others have said, choice is *good*, and since
they're both now GPL, they can cross polinate
each other to improve both projects.
And what compression method will you be using to compress truly random data 2:1?
(Answer: None, since it can't be done, as far as we know.)
Not just as far as we know -- it can't be done,
period. It's easy to mathematically prove it to be
impossible. Assume your new compression algorithm
is capable of *always* compressing random data by
1 bit. Sounds feasible, right? But then that means
you could take the compressed output and feed it
back into the algorithm to further compress it.
This process could be repeated and repeated,
until the original input had been compressed
down to a single bit. Obviously, a 0 or a 1 can't
be uncompressed into an original file. In the
general case, if the original file is n bits long,
then there are 2^n possible permutations. If the
compressed file is n-1 bits long, then there are
2^(n-1) permutations. For compression to be
lossless, each possible source file needs to have
a unique corresponding compressed file. This is
provavly not true, since 2^(n-1) > 2^n. Thus it's
not possible to compress truly random data for
all cases.
Actually, this isn't true. NetBSD have long boasted
about running on more hardware than anyone
else, but in reality, a lot of their architectures
are simply derivatives of an existing architecture.
For example, they treat amiga and atari as separate
platforms, when in fact they're just slightly
different variants of the m68k port. NetBSD
currently runs on 13 different CPU architectures,
only one of which (ns32k) doesn't have a Linux
port. Linux, on the other hand supports 12 of
those 13, plus serveral others that NetBSD doesn't
yet
(power3/power4, ia64, etc.). Not that I
want to put down NetBSD, just correct the
misconception.
they are often more actively maintained (Sparc32 Linux is currently unmaintained, and VAX support seems to have stagnated).
Yep, this I will definitely agree with. Even
ports that were once "mainstream" seem to be
dropping by the wayside, and Linus has stated
that he only really cares about x86 nowadays.
It is only through the tireless work of dedicated individuals like davem and Russell King that
port to other architectures are still kept
mostly in sync with Linus' tree.
That said, in some areas, Linux is stronger, and
in others it's weaker. NetBSD is far closer to
giving me a free OS on my NeXT slab, for example,
whereas Linux is probably a better choice for
the PS2, thanks to official backing from Sony.
BTW, the Linux sparc port is showing signs of
life again, with Pete Zaitcev ensuring recent
kernels are once again working on sparc32,
and heading
towards official maintainership.
It just seems blindingly obvious that free software would give you a much lower TCO than something that comes with massive license fees, regardless of what other factors you work into the equation
It may seem obvious to you, but it's also wrong.
Purchase price / licensing fees typically account
for a very small percentage of TCO. So while free
software may well have lower up front costs, that
doesn't mean the the cost of administering it and
keeping it secure is lower, and hence has less
bearing on TCO than you might think. Of course,
as it turns out, free software typically is
cheaper to run anyway, but that's usually because
it's running on an OS is designed to support
multiple users and remote administration,
rather than because of the lack of license fees...
Re:of course 15 coders makes for less bugs
on
Open Source Studies
·
· Score: 5, Insightful
if these projects average 15 coders, on average they're also significantly less complex projects
If you think that many software projects need more
than 15 coders, you obviously don't have much
experience of software development. In all my years
of software development, I've never seen a core team bigger than 10 people. Sure, Word may
well have 150 developers working on it. But don't
for one second believe they're all actively
coding Word in one big team.
Most will be working in smaller groups of 4 or 5
on one specific area (for example, the spell checker).
I keep hearing this. What is the major unworkable design flaw?
It's based around files, not changesets. That means bulk updates are not atomic, and you can't sensibly migrate multi-file changes between branches.
The design doesn't allow for file renaming.
It's not distributed.
It's based on the RCS file format, which while
fast, is not resilient against corruption. For a source control system, data integrity should rate higher than performance.
CVS or PRCS which arent quite as good but which wont exclude anyone and which will evolve faster if used by such a large project.
CVS is already used by more than enough people.
If it was going to evolve, it would have already
done so. Part of the reason it hasn't is that the
design is fundamentally flawed to start with. It's
easier to start from scratch than it is to fix
the faults of CVS. Which is what PRCS has done
to an extent,
and yes, if kernel developers started using that,
then perhaps it would eventually evolve to the point where
it was as good as BK. But it's not good enough
now, and Linux wasn't/isn't interested in the
political side of using something because it's
free. He's using BK because Larry kept asking
him what he needed to add to BK before Linus was
happy to use it, and he enhanced BK until it
reached that point. Had one of the PRCS (or
subversion, or arch) developers done the same
thing, then maybe we'd be in a similar position but
with a free solution. But it didn't work out
that way. And though he may be a bit hotheaded
at times, I personally believe Larry to be a net
gain to our community. He gives far more than he
takes, and I struggle to criticise him for it...
Rearranging project workflow and starting to form a new one around another system would be the bad thing. Personally, I'd guess it'd cost about 6 months to a year before things got up to speed again.
Yep, and on that point I agree with you, although
I think the 6 months is a little pessimistic.
Not every kernel developer uses BK, and I don't
see that changing in the near future, even if
it was GPLed tomorrow. For those that do,
changing to another system will incur an
overhead, sure, but I'd say 4-6 weeks is more
realistic. Given the likelihood of this worst
case scenario in the first place (low, IMHO,
others may disagree), then I'd say the risk is
small enough to be worth taking for the benefits
using BK brings.
Furthermore the license explicitly forbids interfacting to BitKeeper Packages by any other means than using bitkeeper, unless you comply with the license of the BitKeeper Package, which again means access to the source can be arbitrarily changed to disallow access by interfacing products.
No it doesn't. Read the BKL. What is says is that
if you use BK to access a BK package, then you
may only do so by complying with the license of
that package. If you use other tools to access
the package, then the BK licenses don't come into
play at all.
Do you see the problem and the risk now?
For the kernel, no. Assume the worst. What
happens then? We revert back to the previously
released kernel, and start from there. Actually,
it's not even that bad, because there are several up
to date trees that aren't held in BitKeeper.
So, are you sure enough to pick up the tab, or do you think the kernel should be using a free product for revision handling?
"The kernel" doesn't use any revision control.
Some kernel developers use BK,
and yes, that now includes Linus. Some use CVS.
Some may use others (subversion, arch, etc.).
But the point is, no one is saying you need to use
BK to hack the kernel. Indeed, Alan Cox doesn't.
So where's the problem again? Linus uses it
because it makes his life easier. Prior to using
BK, he didn't use *anything*. If BitMover gets
bought out by MS, then Linus reverts back to
using nothing (or if subversion or some other
free package has improved to the point where it
does what he wants, then he'll use that instead).
There is no risk here. Oh, and BTW, you can't
retroactively relicense a product. Even if MS
did buy BitMover, existing licensees could keep
using the product under the terms of their
original license.
It is not about how buggy CVS is, or how close YOU feel it is. RTFA
Sigh. The "article" is a piece of uninformed and
legally irrelevant speculation by one Debian
developer. What matters in this case is what
BitMover think, and BitMover have repeatedly
stated that they don't see CVS as competition.
This makes RedHat both a reseller and a developer of CVS, and even if he doesn't personally have anything to do with CVS (doubtful) he is forbidden from using the openlogging version.
Nope. You entire argument rest on the premise that
CVS "contains substantially similar capabilities"
to BitKeeper. It doesn't... not just in my eyes,
but in the eyes of Larry McVoy and BitMover. Larry
has repeatedly stated that if CVS was good enough,
he'd never have had to start developing BK in the
first place. CVS is fundamentally flawed in its
design, and doesn't come close to BK in terms of
capabilities. By far the biggest one is its lack
of changesets, but there are others, too.
Hence, RedHat shipping CVS has no bearing on
use of BK by any
RH employees. Now if Red Hat shipped
TrueChange, Perforce, or (more relevant in this case)
Subversion, then it would be a different matter.
And even if they did, I'm sure Larry would make
an exception, or modify the license slightly.
He's a reasonable guy, and wants to do the right
thing, but at the same time, he has a business
to run, and staff to pay, and it's perfectly
reasonable for him to take steps to protect that.
Huh? Diablo... fun? I thought it was boring drivel.
They'd removed all the gameplay, and dumbed it down
so there was no depth to game game at all. Have you
never played the real thing?
You tick the quarter mile in under 12. That's if your foot has the brains to not boil the tires. You're damn near the fastest thing on the planet with four wheels.
Nice though Mr. Lingenfelter's offerings are (and I'd certainly like one!), if you want to claim
fast, even in the road legal category, then you've
got to get down well under 9 seconds. See here
and here, and I'm sure there are faster examples
on the other side of the pond.
You on the other hand, want to force people to watch parts of movies they'd rather not watch.
Not at all. I'm saying that if they object to
the movie in the form the director/studio
originially published it, they have two choices --
either don't watch it, or watch an authorized
abridged version. But a company basing their
existence around commercialized copyright
violation? That's not something I'm going to
support.
We should be supporting them if we agree with the goal of making copyright law more sane, and protecting the right to use products that we purchased, not questioning what they do with that right.
Speak for yourself. I don't support them, and I
don't believe you should either. Despite all the
bile that's been spewed up here, this has
nothing to do with end user
consumer rights. No one is attempting to restrict
personal editing here. The changes aren't being
made for personal use. What they're objecting to
is a commercial company modifying and then
reselling (or republishing, if you like)
their copyrighted work without their
consent. That seems a pretty reasonable objection
to me. After all, you don't expect Readers Digest
to be able to publish an abridged version of a
book without the consent of the original author
and/or publisher. So why do you expect Clean
Flicks to be able to do it?
If you look at this page, you'll see that for some of the features you need a non-free XFree 3.3.6 driver.
Hello? You're buying this box to run X why? In
fact, I think you'll struggle to find pretty much anyone that wouldn't run this headless. Thus the
presence of an XFree86 driver (free or not)
is essentially irrelevant.
Another fun detail on that page : description says : 300 to 400 EUR while it is sold for 590 EUR.
Yep, I've been looking for a small form factor,
fanless PC to use as a firewall for a while. They
all seem to only come with a single NIC. So when
I saw that this openbrick did indeed come with a
dual-NIC option, I was reaching for my wallet to
order one there and then (seriously). It was only
when I got the "configure your box" page, that I
saw the smallprint saying the dual-NIC option was
only available for orders of 70 units or more.
Sigh. Yet another adherent to the "how to lose
potential customers in one easy step" school of
business...
Slashdot Mirror
My favourite Windows related one was so good, I took a screenshot to preserve it for posterity. This was using a Citrix-like multi-user NT system from my Sparc.
For probably the ultimate description of recovering from a screwed system without access to the normal tools, see Al Viro's inhuman heroics here.
*No one* is on call 24x7x365. Well, technically I am, but if I go the the cinema, I turn my mobile off, and work will have to wait. Others can do the same. It's a poor reflection on our times that people think that others can be called any time, day or night. In reality, there's very little that can't wait until the following morning.
Build a Faraday cage over the building before you go in.
Don't know whether you were serious or not, but some UK cinemas have proposed actually doing this. I'm not aware of any that have implemented it yet, but I'm holding out hope...
Actually, IBM make some of the most reliable drives I've ever used. Yes, they had a very high profile failure on one particular range of IDE drives, but I've never had any problems with their SCSI disks.
Sigh. If you actually listened to heavy metal, you'd realise that the quality of both musicianship and recording is significantly higher than mainstream music, and so it's a genre that benefits more from an improved quality format like CDs. Sure, there's a lot of heavy metal that doesn't benefit, but then that's true of every genre (c.f. Sturgeon's Law). Stereotypes may be convenient for some, but as in this case, they're frequently wrong.
Because while Blender may be well endowed with features, its user interface sucks. Really, really sucks. Moonlight 3D (and I admit, I haven't used it in years) had a much better UI. To rework the blender UI would take a lot of work, almost a complete rewrite. Besides, as others have said, choice is *good*, and since they're both now GPL, they can cross polinate each other to improve both projects.
(Answer: None, since it can't be done, as far as we know.)
Not just as far as we know -- it can't be done, period. It's easy to mathematically prove it to be impossible. Assume your new compression algorithm is capable of *always* compressing random data by 1 bit. Sounds feasible, right? But then that means you could take the compressed output and feed it back into the algorithm to further compress it. This process could be repeated and repeated, until the original input had been compressed down to a single bit. Obviously, a 0 or a 1 can't be uncompressed into an original file. In the general case, if the original file is n bits long, then there are 2^n possible permutations. If the compressed file is n-1 bits long, then there are 2^(n-1) permutations. For compression to be lossless, each possible source file needs to have a unique corresponding compressed file. This is provavly not true, since 2^(n-1) > 2^n. Thus it's not possible to compress truly random data for all cases.
Actually, this isn't true. NetBSD have long boasted about running on more hardware than anyone else, but in reality, a lot of their architectures are simply derivatives of an existing architecture. For example, they treat amiga and atari as separate platforms, when in fact they're just slightly different variants of the m68k port. NetBSD currently runs on 13 different CPU architectures, only one of which (ns32k) doesn't have a Linux port. Linux, on the other hand supports 12 of those 13, plus serveral others that NetBSD doesn't yet (power3/power4, ia64, etc.). Not that I want to put down NetBSD, just correct the misconception.
they are often more actively maintained (Sparc32 Linux is currently unmaintained, and VAX support seems to have stagnated).
Yep, this I will definitely agree with. Even ports that were once "mainstream" seem to be dropping by the wayside, and Linus has stated that he only really cares about x86 nowadays. It is only through the tireless work of dedicated individuals like davem and Russell King that port to other architectures are still kept mostly in sync with Linus' tree. That said, in some areas, Linux is stronger, and in others it's weaker. NetBSD is far closer to giving me a free OS on my NeXT slab, for example, whereas Linux is probably a better choice for the PS2, thanks to official backing from Sony. BTW, the Linux sparc port is showing signs of life again, with Pete Zaitcev ensuring recent kernels are once again working on sparc32, and heading towards official maintainership.
It may seem obvious to you, but it's also wrong. Purchase price / licensing fees typically account for a very small percentage of TCO. So while free software may well have lower up front costs, that doesn't mean the the cost of administering it and keeping it secure is lower, and hence has less bearing on TCO than you might think. Of course, as it turns out, free software typically is cheaper to run anyway, but that's usually because it's running on an OS is designed to support multiple users and remote administration, rather than because of the lack of license fees...
If you think that many software projects need more than 15 coders, you obviously don't have much experience of software development. In all my years of software development, I've never seen a core team bigger than 10 people. Sure, Word may well have 150 developers working on it. But don't for one second believe they're all actively coding Word in one big team. Most will be working in smaller groups of 4 or 5 on one specific area (for example, the spell checker).
CVS is already used by more than enough people. If it was going to evolve, it would have already done so. Part of the reason it hasn't is that the design is fundamentally flawed to start with. It's easier to start from scratch than it is to fix the faults of CVS. Which is what PRCS has done to an extent, and yes, if kernel developers started using that, then perhaps it would eventually evolve to the point where it was as good as BK. But it's not good enough now, and Linux wasn't/isn't interested in the political side of using something because it's free. He's using BK because Larry kept asking him what he needed to add to BK before Linus was happy to use it, and he enhanced BK until it reached that point. Had one of the PRCS (or subversion, or arch) developers done the same thing, then maybe we'd be in a similar position but with a free solution. But it didn't work out that way. And though he may be a bit hotheaded at times, I personally believe Larry to be a net gain to our community. He gives far more than he takes, and I struggle to criticise him for it...
Yep, and on that point I agree with you, although I think the 6 months is a little pessimistic. Not every kernel developer uses BK, and I don't see that changing in the near future, even if it was GPLed tomorrow. For those that do, changing to another system will incur an overhead, sure, but I'd say 4-6 weeks is more realistic. Given the likelihood of this worst case scenario in the first place (low, IMHO, others may disagree), then I'd say the risk is small enough to be worth taking for the benefits using BK brings.
No it doesn't. Read the BKL. What is says is that if you use BK to access a BK package, then you may only do so by complying with the license of that package. If you use other tools to access the package, then the BK licenses don't come into play at all.
Do you see the problem and the risk now?
For the kernel, no. Assume the worst. What happens then? We revert back to the previously released kernel, and start from there. Actually, it's not even that bad, because there are several up to date trees that aren't held in BitKeeper.
"The kernel" doesn't use any revision control. Some kernel developers use BK, and yes, that now includes Linus. Some use CVS. Some may use others (subversion, arch, etc.). But the point is, no one is saying you need to use BK to hack the kernel. Indeed, Alan Cox doesn't. So where's the problem again? Linus uses it because it makes his life easier. Prior to using BK, he didn't use *anything*. If BitMover gets bought out by MS, then Linus reverts back to using nothing (or if subversion or some other free package has improved to the point where it does what he wants, then he'll use that instead). There is no risk here. Oh, and BTW, you can't retroactively relicense a product. Even if MS did buy BitMover, existing licensees could keep using the product under the terms of their original license.
Sigh. The "article" is a piece of uninformed and legally irrelevant speculation by one Debian developer. What matters in this case is what BitMover think, and BitMover have repeatedly stated that they don't see CVS as competition.
Nope. You entire argument rest on the premise that CVS "contains substantially similar capabilities" to BitKeeper. It doesn't... not just in my eyes, but in the eyes of Larry McVoy and BitMover. Larry has repeatedly stated that if CVS was good enough, he'd never have had to start developing BK in the first place. CVS is fundamentally flawed in its design, and doesn't come close to BK in terms of capabilities. By far the biggest one is its lack of changesets, but there are others, too. Hence, RedHat shipping CVS has no bearing on use of BK by any RH employees. Now if Red Hat shipped TrueChange, Perforce, or (more relevant in this case) Subversion, then it would be a different matter. And even if they did, I'm sure Larry would make an exception, or modify the license slightly. He's a reasonable guy, and wants to do the right thing, but at the same time, he has a business to run, and staff to pay, and it's perfectly reasonable for him to take steps to protect that.
Of course, there are those of us who believe that Rare lost any magic they once had when they ceased to be ACG in 1985...
Huh? Diablo... fun? I thought it was boring drivel. They'd removed all the gameplay, and dumbed it down so there was no depth to game game at all. Have you never played the real thing?
Nice though Mr. Lingenfelter's offerings are (and I'd certainly like one!), if you want to claim fast, even in the road legal category, then you've got to get down well under 9 seconds. See here and here, and I'm sure there are faster examples on the other side of the pond.
Not at all. I'm saying that if they object to the movie in the form the director/studio originially published it, they have two choices -- either don't watch it, or watch an authorized abridged version. But a company basing their existence around commercialized copyright violation? That's not something I'm going to support.
Speak for yourself. I don't support them, and I don't believe you should either. Despite all the bile that's been spewed up here, this has nothing to do with end user consumer rights. No one is attempting to restrict personal editing here. The changes aren't being made for personal use. What they're objecting to is a commercial company modifying and then reselling (or republishing, if you like) their copyrighted work without their consent. That seems a pretty reasonable objection to me. After all, you don't expect Readers Digest to be able to publish an abridged version of a book without the consent of the original author and/or publisher. So why do you expect Clean Flicks to be able to do it?
Hello? You're buying this box to run X why? In fact, I think you'll struggle to find pretty much anyone that wouldn't run this headless. Thus the presence of an XFree86 driver (free or not) is essentially irrelevant.
Storever are selling it for EUR390.
Yep, I've been looking for a small form factor, fanless PC to use as a firewall for a while. They all seem to only come with a single NIC. So when I saw that this openbrick did indeed come with a dual-NIC option, I was reaching for my wallet to order one there and then (seriously). It was only when I got the "configure your box" page, that I saw the smallprint saying the dual-NIC option was only available for orders of 70 units or more. Sigh. Yet another adherent to the "how to lose potential customers in one easy step" school of business...