CVS is tolerable when you just need a place to store your files while retaining a history of changes. However, if your needs go beyond that, its shortcomings become painfully obvious.
For example, its branching "support" requires you to manually keep track (with tags) of when you branched, so that you have a chance in hell of being able to re-integrate later. Don't even think about just integrating individual changes, either; not only will you not be able to reasonably tag the base for the next integration (unless you like manually specifying the version for every single file), but CVS doesn't even support changesets, so you'll also have to manually figure out what files (and revisions thereof) were part of the change.
And on top of all the design misfeatures, it's simply buggy, in my experience. Numerous times, I've seen bizarre error messages for which I could find no other explanation (such as one commit I attempted that contained two files, which consistently failed, but succeded when I broke it into two separate commits).
Fortunately, I don't have to deal with that crap anymore, as I'm now using Perforce. It's certainly not perfect, but at least it doesn't bite big donkey dick.
You can still overwrite data on the stack, which might still allow you to get a program to misbehave, but at least you're limited to running code that's already in the application.
Not really. You can still control the program flow by overwriting the return address, and given the stack-only parameter passing scheme on x86, you can also supply arguments to whatever function you choose to return to (with register arguments, you'd be limited to whatever registers are going to be loaded off the stack before you return, and argument registers are typically not preserved by the callee). While the typical exploit that just wants/bin/sh to run would likely just call system() or execve() or something, if one really wants to run code from the stack, the stack could be set up to return to memcpy() with the arguments pointing at the code to be moved to an executable area, and a subsequent return value that points to the destination. Null bytes would present a problem with (at least) the length argument, assuming the overflow is from a C-style string, but a sufficiently clever attacker could utilize other library functions to patch in the needed null bytes.
Thus, it may make certain attacks marginally harder, but it doesn't stop foreign code from being executable. It's most visible effect would be the problems it causes to legitimate programs that may want to execute dynamically generated code on the stack.
While there is no silver bullet to these sorts of attacks, making the stack grow upward (or strings grow downward) would eliminate a lot more holes than a non-exec stack. Unfortunately, people are too bound by tradition, and still introduce new ABIs that use downward-growing stacks, even when there's no hardware bias against upward-growing stacks, such as on most RISC chips.
Alphas do not use OpenBoot. They run either
SRM, AlphaBIOS (for NT), or ARC (for NT on
older Alphas). The latter two look and feel
much like a PC's BIOS. The former is command-line
based, but it's still not the same as OpenBoot.
Re:Is it cosher? Is it lenten?
on
Lab-Grown Steak
·
· Score: 2
That's fine, and if the original comment was "Is this food source sustainable?", "Is this food healthy?", or "Are there ethical concerns with this food source?", it wouldn't have received the response that it did. Note that most of the other responses had nothing to do with practicality, but rather what the exact wording of the relevant text is.
Instead, the question is whether it met some specific, several thousand year old rules that people adhere to for religious, not practical, reasons. Furthermore, the original poster didn't just ask about its Kosher status, but also whether it was OK for Catholics to eat on Fridays during lent. In the latter case, I really don't see any practical benefit to a dietary rule that is only followed a few days out of the year.
As for India, should their high population density (and thus difficulty in sustaining cattle farming) stop them from having a burger or a steak if they visit someplace that does have sustainable cattle farming? If you're just going by concerns over sustainability, the answer is no. However, once religion enters the picture, the answer is most likely going to be yes.
Re:Is it cosher? Is it lenten?
on
Lab-Grown Steak
·
· Score: 2
Yes, such dietary laws typically made sense
when they were introduced. How, exactly,
does that make adherence to them today
sensible?
A search at uspto.gov shows that x86
is not a registered trademark in the U.S. (and I very much doubt that it is in China), and I don't recall
Intel using it recently (if ever) in any
official capacity. Given that, how exactly
is either the name "x86" or "the x86 instruction
set" the "intellectual property" of Intel?
You have officially Missed The Point Entirely. When, exactly, was it established that
the only use of the software in question is to
"steal from a company"? That's no more true
than saying that the only use of a gun is to
commit murder.
That Adobe was unable to find
evidence that it was actually being used for
copyright infringement casts quite a bit of doubt
on the notion that that's even the
software's primary purpose.
ARM has a feature that could be considered
MISD, whereby a single instruction can do
a shift/rotate on one operand of an arithmetic or logical
operation (e.g. add r0, r1, r2, lsl #3 to
place the value of r1 + (r2 << 3) in r0).
Not in the U.S., at least. Title 17, section 117
states:
(a) Making of Additional Copy or Adaptation by Owner of Copy. -
Notwithstanding the provisions of section 106, it is not an infringement
for the owner of a copy of a computer program to make or authorize the
making of another copy or adaptation of that computer program provided:
(1)
that such a new copy or adaptation is created as an essential step in the
utilization of the computer program in conjunction with a machine and that
it is used in no other manner, or...
Other than such incidental copies, copyright doesn't cover the use of a work.
Of course, IANAL, and who knows whether or not the courts would simply choose to ignore this as inconvenient, much as they do with certain parts of the U.S. Constitution...
Everybody, that is, except the people that
want *good* optimizations, rather than merely
"sick" ones. Take a look at the code GCC produces
sometime... it's not pretty.
Linux, like any monolithic kernel, gives complete
privilege to drivers (including those for wireless networking
devices), allowing them to crash the system at will. I suggest you invest in some
cough drops.
Yes, they SHIP competing products. That is ever so slightly different from
DESIGNING, where you could use your free copy to steal ideas and features.
The license says that it applies to anyone that sells products wich contain competing functionality; designing it is not a requirement.
Larry simply objects to giving FREE HELP to people who are trying to put him and his colleagues out of business!
Yes, and I don't have an issue with that, although I don't think it would make that much of a difference, given that at least for commercial competitors, they could buy a license and then copy the features... I doubt a couple licenses bought by Rational or Perforce would matter much if they were to come out with a BK-killer... And given that Larry has said that one of the reasons for the free version is to promote Linux work, it doesn't seem unreasonable to say "huh?" when license terms are added that make its use in Linux somewhat awkward.
Larry has gone on the record that he does not regard CVS as competition.
That's nice, though I don't know if it would hold up in court, given the "This License represents the complete agreement between You and BitMover" clause in the license.
However, when asked about versioned filesystems on linux-kernel, he didn't
seem to be as willing to make such an exemption, even though versioned filesystems have uses
other than SCM, and on their own are even less of a competitor than CVS.
BitMover's website seems to imply that they
offer source licenses (presumably for a fee);
why don't you ask them? As for "running all sorts
of processes in the background, or tracking
[your] online behavior", do you have any evidence
whatsoever that they do this? That sort of thing
tends to be discovered without source code, much
less an Open Source license.
And would I buy a car with a hood welded shut? Probably not. But if it met my needs, and all the vehicles with non-welded hoods were go-carts and Pintos, I might consider it.
While I certainly don't speak for RMS's looniness,
this is a rather unfortunate clause given Larry's
stated goal of helping kernel development. Not
only do most Linux vendors ship "competing" products
such as CVS (which Larry handwaved away by
calling it distribution rather than selling,
even when someone pays Red Hat for a CD that contains CVS, and thus
contains functionality that competes (even if pathetically so) with BitKeeper). Furthermore, given the volunteer nature of much of Linux's development, there are many people that would have to go beg Larry for a special waiver to make use of BitKeeper in kernel development simply because of something their employer works on or sells.
It's not that BitKeeper shouldn't have the right to choose to whom they give away their product for free; it's just that many feel that it's not appropriate for something intended to be used to maintain an Open Source project such as the Linux kernel.
They do dual license; there's one license for
free-as-in-beer use, and another, less restrictive
license for people that pay for the product.
Oh, wait, you want one of those licenses to
be Open Source because you feel you have an
entitlement to use their product for free on terms of your choosing,
and somehow the existence of another license is going to make the Open Source Fairy fly by and pay the bills.
Sorry, I forgot.
Regardless, it is a point of incompatibility. The reason I'm aware of the bug is because of reports I've seen of customers linking our code against code built with 2.96, and experiencing failures as a result. Thus, code exists that is affected by the bug. Whether the "majority" of apps use this feature, or whether the apps you use use it (have you grepped every bit of source code you run? You may find the Linux kernel to be an interesting place to look...), is irrelevant.
And no, the answer is not to remove the alignment, as it speeds up array accesses by making the size of the struct a power of 2.
So perhaps GNOME doesn't use the "aligned" attribute. One example of something working does not mean that everything is compatible. And what exactly do you mean by "disabled by default"? It's not a flag you turn on, but rather a feature that code can use. You don't see it being used unless you look at the code.
Try the following code on 2.96, and compare the results with any other version of GCC (x86 only; the bug doesn't seem to happen on Alpha, and I haven't tried other architectures):
#include <stdio.h>
typedef struct { int foo, bar, baz; } __attribute__((aligned(16))) s1;
typedef struct { int x; s1 y[2]; } s2;
int main(void) { printf("%d\n", sizeof(s2)); return 0; }
Sorry about the formatting, but slashdot doesn't allow <pre> for some reason, and <ecode> strips out indentation.
On all *official* GCC versions, perhaps (if
you ignore #ifdefs based on the GCC version,
for the purpose of using new features or
avoiding bugs in certain versions). However,
Red Hat's 2.96 abomination is *not* compatible
with other GCC versions, even for C. It ignores
the "aligned" attribute when laying out structs,
so if you have a struct containing types with
specified alignment (I'm not sure what it does
if you specify the alignment for the datum itself), that struct will have a different layout with 2.96 than with other GCC versions.
It's already the case that almost nobody
can support themselves solely through their music;
however, with a more direct distribution system,
the promotion of bands would be more decentralized,
which would likely lead to more variety in the
handful of bands that reach a sufficient popularity
level that they can live off of their music.
From Article III, Section 3 of the U.S. Constitution:
Treason against the United States, shall consist only in levying War against them, or in adhering to their Enemies, giving them Aid and Comfort.
Disobeying an order from the President will
likely get a member of the military in a lot
of trouble, but unless it meets the above criteria,
it cannot be considered treason.
It may encourage the creation of certain works,
but it also discourages the creation of others. As
has been pointed out elsewhere in this discussion, many of
Disney's films are derivative of works in the
public domain. If those works had not been in the
public domain, it would have served to discourage
Disney from creating those works.
Thus, it is far from clear that the net
change in encouragement to create is positive
with a longer copyright term.
Slashdot Mirror
For example, its branching "support" requires you to manually keep track (with tags) of when you branched, so that you have a chance in hell of being able to re-integrate later. Don't even think about just integrating individual changes, either; not only will you not be able to reasonably tag the base for the next integration (unless you like manually specifying the version for every single file), but CVS doesn't even support changesets, so you'll also have to manually figure out what files (and revisions thereof) were part of the change.
And on top of all the design misfeatures, it's simply buggy, in my experience. Numerous times, I've seen bizarre error messages for which I could find no other explanation (such as one commit I attempted that contained two files, which consistently failed, but succeded when I broke it into two separate commits).
Fortunately, I don't have to deal with that crap anymore, as I'm now using Perforce. It's certainly not perfect, but at least it doesn't bite big donkey dick.
Not really. You can still control the program flow by overwriting the return address, and given the stack-only parameter passing scheme on x86, you can also supply arguments to whatever function you choose to return to (with register arguments, you'd be limited to whatever registers are going to be loaded off the stack before you return, and argument registers are typically not preserved by the callee). While the typical exploit that just wants /bin/sh to run would likely just call system() or execve() or something, if one really wants to run code from the stack, the stack could be set up to return to memcpy() with the arguments pointing at the code to be moved to an executable area, and a subsequent return value that points to the destination. Null bytes would present a problem with (at least) the length argument, assuming the overflow is from a C-style string, but a sufficiently clever attacker could utilize other library functions to patch in the needed null bytes.
Thus, it may make certain attacks marginally harder, but it doesn't stop foreign code from being executable. It's most visible effect would be the problems it causes to legitimate programs that may want to execute dynamically generated code on the stack.
While there is no silver bullet to these sorts of attacks, making the stack grow upward (or strings grow downward) would eliminate a lot more holes than a non-exec stack. Unfortunately, people are too bound by tradition, and still introduce new ABIs that use downward-growing stacks, even when there's no hardware bias against upward-growing stacks, such as on most RISC chips.
Alphas do not use OpenBoot. They run either SRM, AlphaBIOS (for NT), or ARC (for NT on older Alphas). The latter two look and feel much like a PC's BIOS. The former is command-line based, but it's still not the same as OpenBoot.
Instead, the question is whether it met some specific, several thousand year old rules that people adhere to for religious, not practical, reasons. Furthermore, the original poster didn't just ask about its Kosher status, but also whether it was OK for Catholics to eat on Fridays during lent. In the latter case, I really don't see any practical benefit to a dietary rule that is only followed a few days out of the year.
As for India, should their high population density (and thus difficulty in sustaining cattle farming) stop them from having a burger or a steak if they visit someplace that does have sustainable cattle farming? If you're just going by concerns over sustainability, the answer is no. However, once religion enters the picture, the answer is most likely going to be yes.
Yes, such dietary laws typically made sense when they were introduced. How, exactly, does that make adherence to them today sensible?
A search at uspto.gov shows that x86 is not a registered trademark in the U.S. (and I very much doubt that it is in China), and I don't recall Intel using it recently (if ever) in any official capacity. Given that, how exactly is either the name "x86" or "the x86 instruction set" the "intellectual property" of Intel?
That Adobe was unable to find evidence that it was actually being used for copyright infringement casts quite a bit of doubt on the notion that that's even the software's primary purpose.
Actually, instructions on Alpha take only 32 bits each, not 64 or 256.
ARM has a feature that could be considered MISD, whereby a single instruction can do a shift/rotate on one operand of an arithmetic or logical operation (e.g. add r0, r1, r2, lsl #3 to place the value of r1 + (r2 << 3) in r0).
Of course, IANAL, and who knows whether or not the courts would simply choose to ignore this as inconvenient, much as they do with certain parts of the U.S. Constitution...
Everybody, that is, except the people that want *good* optimizations, rather than merely "sick" ones. Take a look at the code GCC produces sometime... it's not pretty.
Linux, like any monolithic kernel, gives complete privilege to drivers (including those for wireless networking devices), allowing them to crash the system at will. I suggest you invest in some cough drops.
And would I buy a car with a hood welded shut? Probably not. But if it met my needs, and all the vehicles with non-welded hoods were go-carts and Pintos, I might consider it.
It's not that BitKeeper shouldn't have the right to choose to whom they give away their product for free; it's just that many feel that it's not appropriate for something intended to be used to maintain an Open Source project such as the Linux kernel.
Oh, wait, you want one of those licenses to be Open Source because you feel you have an entitlement to use their product for free on terms of your choosing, and somehow the existence of another license is going to make the Open Source Fairy fly by and pay the bills. Sorry, I forgot.
And no, the answer is not to remove the alignment, as it speeds up array accesses by making the size of the struct a power of 2.
Try the following code on 2.96, and compare the results with any other version of GCC (x86 only; the bug doesn't seem to happen on Alpha, and I haven't tried other architectures):
Sorry about the formatting, but slashdot doesn't allow <pre> for some reason, and <ecode> strips out indentation.
On all *official* GCC versions, perhaps (if you ignore #ifdefs based on the GCC version, for the purpose of using new features or avoiding bugs in certain versions). However, Red Hat's 2.96 abomination is *not* compatible with other GCC versions, even for C. It ignores the "aligned" attribute when laying out structs, so if you have a struct containing types with specified alignment (I'm not sure what it does if you specify the alignment for the datum itself), that struct will have a different layout with 2.96 than with other GCC versions.
How would "they" know that your wife isn't looking over your shoulder if you fill out an absentee ballot?
Unless, of course, said geek is an Emacs or vi fan.
It's already the case that almost nobody can support themselves solely through their music; however, with a more direct distribution system, the promotion of bands would be more decentralized, which would likely lead to more variety in the handful of bands that reach a sufficient popularity level that they can live off of their music.
Thus, it is far from clear that the net change in encouragement to create is positive with a longer copyright term.
You were willing to spend a whole day researching prices, but you weren't willing to spend an extra hour or so to put the parts together?