I believe one of the points in the paper is that the operating systems surveyed have a seperate TSopt clock than the system clock. For example, it sounded like Linux's TSopt clock is based on jiffies, which are incremented by the hardware timer (100 Hz in linux 2.4, 1000 in 2.6). Therefore it makes no difference whether or when you run NTP, TSopt measurements will reflect the hardware timer's skew regardless.
Without a doubt, most open-source software infringes on patents. So does most commercial software, as does any non-trivial software.
Open Source Risk Management is a company that wants to insure companies against potential open source copyright/patent problems. Pamela Jones (of groklaw fame) and Bruce Perens are involved. OSRM released a whitepaper saying that at least 283 patents could potentially be used in litigation over the Linux kernel.
So wait... One ounce of stuff is equivalent to 85 million tons of TNT, hence 85 million tons of TNT is equivalent to 2.3e20 tons of TNT is equivalent to 6.3e32 tons of TNT is equivalent to... Hmm, that's a lot of TNT!
I hate new windows too. I could never get any extension to eliminate new windows working, but I just tried this tip today and it seems to work, no extension needed. I'm not sure why, but I haven't seen any of the popups on sites people are mentioning here.
By your argument, Linus is unfit to develop the Linux kernel. In case you haven't noticed, Linus has been adding lots of type annotations above and beyond what C supports, and checking them with the semantic analyzer he wrote. Not only that, but it's caught lots of errors, so apparently he's not the only unfit kernel developer.
It sounds like my university has an identical computer graphics class to yours. I'm very disappointed. It doesn't help that our book's source code was written by an obvious amatuer (Computer Graphics Using OpenGL, 2nd ed.).
What really bugs me is that most of my peers haven't learned to use any particular language effectively, nor have they learned the fundamentals very well. And here our intern coordinator is always raving about how much companies like our interns compared to other schools!
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
The GPL is a redistribution license, permitting you to do things which you otherwise legally couldn't.
Whereas EULAs purport to be contracts, pertaining to use of the software and restricting fair-use rights.
Hooks are client-side-only. Since arch doesn't count on a particular storage backend or access method, it means you can't write hooks that force, for example, certain tests, or does notifications, upon commit or other actions on the tree. I think this is a more serious weakness; but to fix it might mean giving up the advantages of a server-free implementation.
The way around this is with a patch-queue manager such as Arch-PQM. This lets you run hooks on the pqm-managed tree when you submit patches to it, effectively giving you server-side hooks.
DVDs don't "have" Macrovision. Macrovision is done by the player or the TV out chip, dependant on whether the DVD has a Macrovision "activation code." Reference.
Id Software, though, knows a few things about source code leaks. Several of the company's biggest games, including all of the Quake games, have seen their source code leak out. Last year, a playable build of the still-in-development Doom 3 hit the Internet.
From here. I don't think they're confusing it with the GPL source releases, either.
auto_ptr doesn't do reference counting. It maintains the invariant that only one instance of auto_ptr owns the pointer, by transferring ownership on each assignment. When the owning copy goes out of scope, the pointer is freed. The only run-time overhead should be a few pointer assignments.
Those function calls you mention are templates; they compile away to nothing more than the equivalent operations on a pointer.
The AC seems to have a good description of the efficiency, at least if I implemented it in the standard way. I'm not sure if the C code could be optimized much further. All that bit munging to pack the bitmap costs CPU time in exchange for lower memory usage. OTOH, the improvement in cache hit rate may make up for it.
You can calculate an upper bound on the magnitude of the n'th prime, so you could just replace my sneaky;-) choice of count with that.
I'm too lazy to type it in slashdot, but I put the C version here.
It seems to be slightly worse than O(n). Actually, I think I might be able to do better in Haskell using a list of the composites instead of the primes, since those can be generated as a list of multiples instead of using the modulus.
I wrote a Sieve of Erasthones program in Haskell yesterday, and although it's amazingly short, and easy to understand (after you get your head around infinite lazy lists;-), it's also terribly inefficient (big O-wise, it seems), at least compared to a version I wrote in C. I think it would run faster if I let the garbage collector use more memory, but I haven't looked into that.
So, functional programmers, how to improve such a program without simply mimicking the imperative version?
import System
import Numeric
x `divides` y = y `rem` x == 0
sieve:: [Int] -> [Int]
sieve (x:xs) = x : sieve [y | y <- xs, not (x `divides` y)]
primes = 2: sieve [3,5..]
-- sieve [2..] would also work
main = do args <- getArgs
let count = fst (head (readDec (head args))) in
putStr ((show (take count primes)) ++ "\n")
It looks like Gnumeric improved or stayed the same on every data point except Pidigits, Numacc2, and Origin1 (whatever those are). Note that the LRE is the negative of the log of a value less than one, so a larger LRE means a smaller relative error. It's just the number of digits that agree with the correct answer. Really bad values would even have a negative LRE.
Not quite an example, but actions taken by the mICQ author really upset some people. He made mICQ build and work on the Debian maintainer's machine, but then fail on users' machines, and the change was made in a nice obfuscated manner. A fair number of users will probably not trust his code in the future.
Although the Debian maintainer certainly shares some responsibility for not noticing the change.
It's a little difficult to ask google about something which consists of just a letter and an asterisk, with no context, even if you know it's pronounced "a star." Unless you know something about google I don't...
I think that timothy must've posted this without reading the article itself -- or I've read the wrong article -- but the article author _NEVER_ says 'untested and therefore insecure'....
Not in those exact words, but he pretty much does. From the article:
Yet another problem with IPv6 has to do with all of the impending security problems it will cause.... But what IPv6 boosters won't tell you, unless you press them, is that every new IPv6 nameserver, Web server, Web browser, and so on has new code--code in which security problems may lurk. Indeed, security problems with new protocol implementations are to be expected. And while some issues have been found with these new IPv6 servers, more are sure to be discovered.
Page 2. Personally, I read the article as rather alarmist. I also find it rather unlikely that the use of NAT is currently a serious impediment to file-sharing, so I don't see the RIAA becoming concerned about IPv6.
Slashdot Mirror
What awful type punning!
I believe one of the points in the paper is that the operating systems surveyed have a seperate TSopt clock than the system clock. For example, it sounded like Linux's TSopt clock is based on jiffies, which are incremented by the hardware timer (100 Hz in linux 2.4, 1000 in 2.6). Therefore it makes no difference whether or when you run NTP, TSopt measurements will reflect the hardware timer's skew regardless.
Open Source Risk Management is a company that wants to insure companies against potential open source copyright/patent problems. Pamela Jones (of groklaw fame) and Bruce Perens are involved. OSRM released a whitepaper saying that at least 283 patents could potentially be used in litigation over the Linux kernel.
So wait... One ounce of stuff is equivalent to 85 million tons of TNT, hence 85 million tons of TNT is equivalent to 2.3e20 tons of TNT is equivalent to 6.3e32 tons of TNT is equivalent to ... Hmm, that's a lot of TNT!
I hate new windows too. I could never get any extension to eliminate new windows working, but I just tried this tip today and it seems to work, no extension needed. I'm not sure why, but I haven't seen any of the popups on sites people are mentioning here.
By your argument, Linus is unfit to develop the Linux kernel. In case you haven't noticed, Linus has been adding lots of type annotations above and beyond what C supports, and checking them with the semantic analyzer he wrote. Not only that, but it's caught lots of errors, so apparently he's not the only unfit kernel developer.
What really bugs me is that most of my peers haven't learned to use any particular language effectively, nor have they learned the fundamentals very well. And here our intern coordinator is always raving about how much companies like our interns compared to other schools!
worse thæn useless?
SCO also distributed 2.4.19 as recently as last August, although the link no longer works.
DVDs don't "have" Macrovision. Macrovision is done by the player or the TV out chip, dependant on whether the DVD has a Macrovision "activation code." Reference.
Gnome does, assuming it's compiled for a 486. Win95 doesn't like Athlons.
If you really wanted, you could #define in <= for example, where <= would be your inclusion operator.
See the video here, along with many more gems.
Those function calls you mention are templates; they compile away to nothing more than the equivalent operations on a pointer.
You can calculate an upper bound on the magnitude of the n'th prime, so you could just replace my sneaky ;-) choice of count with that.
I'm too lazy to type it in slashdot, but I put the C version here. It seems to be slightly worse than O(n). Actually, I think I might be able to do better in Haskell using a list of the composites instead of the primes, since those can be generated as a list of multiples instead of using the modulus.
So, functional programmers, how to improve such a program without simply mimicking the imperative version?
Slashdot ate my spaces.It looks like Gnumeric improved or stayed the same on every data point except Pidigits, Numacc2, and Origin1 (whatever those are). Note that the LRE is the negative of the log of a value less than one, so a larger LRE means a smaller relative error. It's just the number of digits that agree with the correct answer. Really bad values would even have a negative LRE.
Although the Debian maintainer certainly shares some responsibility for not noticing the change.
It's a little difficult to ask google about something which consists of just a letter and an asterisk, with no context, even if you know it's pronounced "a star." Unless you know something about google I don't...