Slashdot Mirror

This is what I hate about most "traditional" news sites -- they tell you the image exists, but they don't say where. NASA makes much of its imagery available on the web, so there should always be a link. To be fair, IBI (as well as the above link) appears to have published the highest resolution available. But for completeness, here is NASA's original:

USA7 Subsets Day 118: 04/28/11
Page for Aqua 250m True Color
Direct link to image (8MB)

I think you have the obligation here.

The subset-difference algorithm takes some effort to explain properly, and I will not go into that just because somebody on the internet is too lazy to look up the references themselves. I can, however, supply the required Google search:
http://www.google.co.uk/search?q=subset-difference &start=0&ie=utf-8&oe=utf-8

As for the reverse engineering you're talking about the first device.

Re-read my reply, where I specifically addressed that already. The reverse engineering part applies mostly to the first device. The actual physical work of stripping and scanning a circuit applies to every subsequent attempt too.

First off, a distinction is to be made (after I say IANAL) -- Fair use is not legally a "right" -- it is an "affirmative defense" to a charge of infringement. As such, it does not come into play until after a verdict if infringement has been rendered. i.e., you have already been judged guilty.

Well, it's clear that you've looked into this a little bit, but perhaps not enough.

Fair use isn't a right. Nor is it actually an affirmative defense, although that's procedurally how it is treated. This isn't surprising; copyright doesn't really grant rights to affirmatively do anything. That's not how it works for anyone.

Fair use is an exception to copyright. Think of a Venn diagram, in which you have a set, a subset, a sub-subset, a sub-sub-subset and so forth.

At the top is free speech, a guaranteed right. Copyright applies to a subset of this speech. Copyright itself is riddled with exceptions, which remove copyright from certain aspects or uses of certain works. And sometimes those exceptions have exceptions that bring copyright back into play, and then sometimes those exceptions have yet more exceptions that eliminate the copyright yet again.

An example: You have a right of free speech, which permits you to distribute copies of works that someone else made. If that work is not copyrighted, then that's the end of the analysis: you have a right to distribute copies of it, barring something else that might limit your free speech (e.g. libel laws, if the work is libelous). If the work is copyrighted, then someone else has a right to prohibit you from distributing copies, essentially shutting down your right of free speech with regard to distributing that work. But, if that copy was lawfully made under US copyright law, and if you own that copy, then copyright does not apply to its distribution. This means that as far as distribution goes, for those things that qualify, you're back to merely exercising your free speech rights. Copyright doesn't grant you a right to distribute it, e.g. to sell a used book to a bookstore, it just grants or doesn't grant someone else a right to stop you. But suppose the means by which you want to distribute the copy is by renting it, and the copy is a computer program. Then the exception has an exception to it, and copyright law once again applies, and you can be prohibited from renting that. But suppose further than the computer program is a video game cartridge for a console. Then there's an exception to the exception to the exception, and you can rent that without permission or payment, so long as you own the lawfully made copy.

This is all taken from 17 USC 109, which deals with the First Sale doctrine.

So no, Fair Use isn't a right, but it merely prohibits copyright from interfering with the underlying right of free speech which is a right.

Procedurally, it is treated as a defense, because it is felt to be fairer all around if, instead of plaintiffs having to prove that the complained-of use is not a fair use in order to make their prima facie case, defendants should have to prove that the use is a fair use (if they want to; they're not obliged) in order to defend themselves against a plaintiff who has made out a prima facie case of infringement. After all, if no one claims it's fair, why should the plaintiff have to waste time with it? And if it is claimed to be fair, wouldn't the defendant be in a better position to gather evidence to prove this?

Also, note that you're wrong about in what order things come. In a court case, the plaintiff (or prosecutor) has to first make their prima facie case. For example, suppose you were accused of murder. The murder victim is known to be alive and well. In that case, the prosecutor cannot prove that you murdered the living victim. You, the defendant, win the case, without having to defend yourself or even lift a finger, because the prosecutor didn't get far enough with his side of things. Likewise in copyright infringement suits, fair use simply isn't necessary until it can be shown that the

So you're using 'non-standard' features and you're suprised that other implementations don't have them? Do you really care about portability then or not?

You're looking at this very differently from the way most developers look at it. It's no longer necessary to write a portable Makefile because we have a make (GNU make) that is itself portable. You write your Makefile to that specification, avoiding the greatest-common-subset (a.k.a. dumbest-possible-subset) problem and expect GNU make to be installed everywhere. The features of GNU make are so incredibly useful that they are now de facto standards. Any userland that doesn't support them is broken.

The same argument applies to textutils. Shells are a little more problematic simply because for some reason some admins don't like to install additional shells and set up /etc/passwd correctly. So we still need to deal with dumb, dumb, DUMB Solaris shell problems. Try bootstrapping gcc on Solaris for a wonderfully painful example.

Absolutely right. It does seem people have jumepd the gun on this. Whilst it is certainly an impressive feat of debugging/disassembly, the AACS scheme itself has not been cracked or compromised.

AACS were aware, like almost everyone on this forum, that media keys and even device keys will be leaked out of a player somewhere given enough effort. Indeed, the same argument holds for the content itself - if it can be viewed then it exists decrypted somewhere.

This is why at the heart of AACS is a revocation algorithm significantly more advanced than CSS (which allows revocation of a player key that is shared between many players of a manufacturer etc). In other words, every future disc pressed can revoke this player (WinDVD). AACS can cryptographically revoke any particular player or set of players it likes without significant overhead. For those interested, the subset-cover algorithm does about 1.25 subset-differences per revocation, and each entry for a subset-difference is 16+5 = 21 bytes, so every player in the world that is eventually revoked only adds 26 bytes to the MKB (disc header) of every disc produced from the on.

Actually I should include a shameless plug on a posting of mine which attempts to explain how this algorithm works, if you're _really_ interested.

Another poster responded to this parent that revoking WinDVD would inconvenience a lot of people using this player. And that I think is one of the weaknesses of the implementation of AACS - software players. On the other hand, it is fairly easy to update a software player over the internet to use new keys, but all any new version of WinDVD would be doing is hiding its AACS code/keys in more obscure ways, which we know is like throwing a chair in the path of someone chasing you =)

> 0. C++ (at one time, at least) EXTENDS C
> ...
> 2. C++/CLI LIMITS C++ (no multiple inheritance, no metaprogramming, etc etc) -- more than it extends it (.net class libraries)

According to Strousop, C++ is not entirely a superset of C either.

"In the strict mathematical sense, C isn't a subset of C++. There are programs that are valid C but not valid C++"

Source: http://public.research.att.com/~bs/bs_faq.html#C-i s-subset

I wrote a program that knew it's own syntax in subset-of-C parse tree (basically it's genetic code).

What it would do was to create two mutants of it's parse tree, generate the c code from the mutants, compile them, then fork, execing both children executables. This had the benefit of every children always being compilable, and the "DNA" being somewhat less brittle. (Every child did *something*, even if it wasn't able to reproduce.)

It was pretty slow, but eventually crashed my system. In the process though, it *did* manage to complexify itself adding a few lines here and there, and cut out some code I thought was necessary but turned out wasn't, streamlining itself for it's competition for compiler time, I guess.

Anyway, I thought it wasn't too interesting because my little subset had no IO capabilities beyond being able to summon gcc onto the results of STDOUT, and it's sole selection criteria was speed through the compiler. I also just now realize that eventually one would mutate into a simple fork bomb and all evolution would stop.

With a better c-subset and a more interesting selection environment, it could possibly be cool.

It is even better than that, provided that the JIT compiler is correctly implemented. If you implement an interpreter in a language that is being JIT compiled, then that program that is being interpreted will also be JIT compiled (due to transposition).

With the PyPy (Python) compiler they showed that can be true. The project is pretty insane though, hold on to your hats:
- They wrote a language that is a subset of Python which could be completely compiled. It has full type inference, and static typing.
- They added some JIT compile trickery, to recognise interpreter constructs.
- Then they wrote a Python interpreter in this subset-Python.
- Now any Python program that is being interpreted will be JIT compiled.

From the documentation, it says that if you make another language interpreter in this subset-Python, it will also get JIT compiled.

Old-timer here.
In my time, I have programmed in assembly ( Intel, Motorola, and Apple II + ), C, C++, VB, VBA, Python, Java, javascript, amd more.
This smells like a popularity poll, and the newest and shiniest win.
The real winners are the HR people who read this to check for buzzwords.
As always, choose the right language for the job. If you don't know it, learn it.
( Just because you have orgasms in javascript does not mean it can be used everywhere - hammer/tool/nail - get more tools! ).
C and assembly for speed, and hardware interaction. C++ with C-subset for almost anything else.
Lisp for the ultimate obfiscation.
Java, Python, Perl, Ruby, javascript for web stuff.... and not always - if a web back-end could better be done using C++, then use it.
Of course, management always trumps practicality and intelligence - bummer.
And the sales people always lie.

You know you look ridiculous announcing your emotional problems, then attacking Reddit over what a small-subset of users did, on a site as far gone as Slashdot is.

Apple, OTOH, made the whole thing COMPLETELY SEAMLESS to all but the smallest-subset of users, by clever OS witchery (which I freely admit I do not know for sure how it works, but I assume has something to do with having a 32 bit and 64 bit version or entry point to each API call).

The way the "compatibility mode" kernel that shipped on Mac OS X several years ago works: the kernel is double-mapped into both the low 4G of the address space as well as the upper 128 TB ("negative") region. On a system call, exception or interrupt, the processor branches to the "high" double mapped region, switches to 64-bit mode and executes a small slice of the kernel in 64-bit mode. That slice does some book-keeping and then switches address spaces and modes to execute 32-bit "compatibility" mode IA32 code back in the low 4GiB. With this mechanism, 64-bit programs work without requiring all the 32-bit drivers and the kernel proper to operate entirely in 64-bit mode, which was a significant time-to-market and compatibility advantage. There's a drawback in that performance isn't as good as with a pure 64-bit kernel, but Apple shipped that a few years later.

I dont normally defend MS, but when your OS is in 95% of all the computers in the world you cant get away with these changes in the way Apple can. When Apple has ATM's running on OS X etc.. I'll give them credit for keeping up to date. Windows' main selling point is its Achilles heel. Backward compatibility always sets MS back.

Sorry, but the rubric of "backwards compatibility" won't work this time.

The fact is, when Windows started down the 64 bit path, they COULD have done what Apple did with OS X, but they chose not to. Instead, they drew a big, fat NON-COMPATIBILITY line in the sand between 32 and 64 bit land, and, far too often, made USERS have to do the legwork.

Apple, OTOH, made the whole thing COMPLETELY SEAMLESS to all but the smallest-subset of users, by clever OS witchery (which I freely admit I do not know for sure how it works, but I assume has something to do with having a 32 bit and 64 bit version or entry point to each API call).

That has nothing to do with "backward compatibility"; because Apple was able to do its SEAMLESS 32 to 64 bit transition while RETAINING COMPATIBILITY with 32 bit Applications and in most cases, even drivers, as if nothing ever happened.

No need for "Program Files (x86)", separate 32 and 64 bit Installers and Apps, let alone drivers.

Sorry, painless "Backward Compatibility" is EXACTLY what OS X accomplished for nearly all users and all applications, and EXACTLY what Windows did NOT give.

It has a LOT more to do with good OS design than it does with the size of the install base or number and/or breadth of applications.

Do you really think that in a room somewhere, the discussion went like the following?

Engineer: "So we had this idea to require kext signing to increase security. What do you think?"
Manager: "PERFECT. This will totally fuck over all those cheap bastards that buy a 3rd party SSD and then turn on TRIM anyway! I LOVE IT!!"
Engineer: "Uhm... we were talking about a security issue. How did you leap to one minor only-experienced-by-a-small-subset-of-users thing instantly?"
Manager: "Because I'm an EVIL MONEY GRUBBING CORPORATE OVERLORD, and this is a hypothetical conversation on Slashdot!"
Engineer: "..."

Is that more likely than this is merely an undesirable side-effect of Apple making their OS more secure? They don't turn on TRIM because there are older drives out there that totally suck at it and vomit on themselves if it's enabled - which is why Linux has a blacklist in it's AHCI drivers. Apple isn't going to test TRIM functionality on every SSD ever manufactured - they're going to QA against what they ship, like any other company would.

Besides, it's trivial to turn off the kext signing and re-enable TRIM if you're that worked up about it. sudo nvram boot-args=kext-dev-mode=1

Just don't ever clear the nvram and reboot, or you won't be able to load your hacked AHCI kext until you re-introduce that NVRAM flag from recovery mode.

I think that you have your math wrong. Number one, you don't know who you are comparing the face of so according to your schema you would need to do 10,000 * 10,000 comparisons, since you don't have a way to say "Oh! This is John Derp's face, so let's only compare it to the other 9,999 faces!". Also, you don't compare each face with everyone else's, you only compare with a list of known crooks (hopefully not EVERYONE'S face is in the system, although I am not sure of anything these days).

Then, assuming there are 100 known crooks in the 10,000 population, you do 10,000 * 100 comparisons and, assuming the same error rate of 1 in 1,000 you get 1,000,000 / 1,000 = 1,000 errors. Which is not nearly as high but definitely not ideal.

I henceforth name this the subset-birthday paradox!

Nevertheless, she was using powers granted by the company to enforce her will; from the customer's perspective, SWA was acting to prevent his family-subset from flying.

If she's had said... "unless you delete that tweet, I will not speak to you during the flight" that would have carried less weight and might have been interpreted as personal.

Look, this is not a nerd problem. This is not a subset-of-men problem. The problem is simplified as "misogyny" and that's it.

Yes, there are misogynist nerds. But to be frank, let's call 'em what they are - misogynist. Because there are misogynist Christians, there are misogynist atheists, there are misogynist railfans, there are misogynist bus drivers, there are misogynist flautists. it does not matter what group they are part of, a misogynist is a misogynist.

I'd say "fuck them", but that would be a lowering of standards. I suggest not fucking them.

I believe they designed servers and integrated some smart software to be able to do that with great performance.
But you can duct-tape this kind of recovery on commodity servers if they boot via PXE/TFTP on a rudementary but very effective level though, in tandem with one configuration channel each that you could have fallback for quite simply.

I imagine rollout scripts would first check if rollout to a test-subset is succesfull before continueing with all production servers. I speculate this article might just be about this subset, but story being spiced/beefed up in spite of more exceting/serious errors at server heaven.

Trademark infringment is not a subset of fraud. Trademark law came out of the tort of passing off, which originally was a descendant of fraud/deceit, but they're now different in that fraud happens between the lier and the listener; trademark infringement happens between the lier and the owner of the mark that they co-opt. It isn't a subset-superset relationship anymore.

If a person does not abide by the terms of the GPL, however, then the permission that the GPL grants does not apply to that person, and so could be found guilty of copyright infringement when making copies of the work that do not fall within the boundaries of fair use.

Copyright is about more than just fair use, you know.

It may help to think of copyright by means of a Venn diagram. It's like a subset that is, itself, full of sub-subsets that compromise holes in what the subset contains.

The largest set is the public domain. Anything in the public domain can be used freely, in any way, so far as copyright is concerned. (Because we're talking about copyright, and not, say, personal property, note that a copy of a work can still be owned and off-limits even though the creative work embodied in that copy is not protected. For example, the Mona Lisa is in the public domain, but the actual wooden painting made by Da Vinci is heavily guarded. Copyright might not give anyone the right to stop you from making a copy of the Mona Lisa, but the Louvre doesn't have to let you take a photograph of it.)

Works that are copyrighted fall partially into the subset of copyright. Partially, not wholly, because copyright only applies to certain types of action with regard to a work. For example, making a new copy of a work by reproducing it is one of the exclusive rights of copyright. But using a book (which is a copy of a work) to prop up an uneven bedframe is not an infringement of copyright, because the law does not grant copyright holders an exclusive right of 'propping-up.' Likewise, some kinds of works are not copyrightable. In the US, from 1790 on, only books and maps could be copyrighted. Only when the law was amended in 1802 were some engravings copyrightable. In 1831, all engravings, and also musical compositions; 1856, dramatic works; 1865, photographs; 1870, paintings, sculptures, drawings, and models and designs of works of fine art; 1912, motion pictures qua motion pictures (previously they were claimed as collections of photographs); 1971, sound recordings; 1976, pantomime and choreography as themselves, as opposed to being dramatic works; 1990, architecture. Anything not on the list of protected types of works is in the public domain. (Software, in case you're wondering, is treated as a literary work, like a book, but doesn't yet have its own category) There are a few other limits on what is copyrightable, but they're not terribly important for our purposes.

Of the list of enumerated rights which compromise copyright, and which is short in comparison to the list of all rights concerning those works and their copies, as applied to those works which are eligible for copyright, which is less than the totality of all works, there are still some subsets which further limit copyright protection.

Fair use is one of them -- any otherwise infringing use, which is fair, is not infringing. That's a fairly good-sized hole in the already swiss-cheesed set of copyright. First sale is another big one -- the right of the copyright holder to control the distribution of copies is almost entirely obliterated once the copyright holder has sold the copies in question. There are some exceptions to that exception, and some exceptions to those exceptions to the exception, but it's still shrinking copyright. Another one you might enjoy for software is that if a person owns a copy of a program, he can copy it and modify it in order to make it work, without needing permission. Likewise, he can make backups without permission. So really, so far as copyright goes, people in the US only need to agree to the GPL to copy a work if they're going beyond the statutory exception that keeps copyright from stopping them making certain copies.

There are exceptions like this throughout the Copyright Act. They can be broad, they can be narrow, they can be subject to various conditions and exceptions themselves. But the point remains that copyright is an all-encompassing, all-covering blanket. I

This is a case of confusing UI defaults, I think, but given that *I* also got caught by it (and was mortified), even though LinkedIn isn't "hacking" anybody, I don't have a lot of sympathy for them (LinkedIn--have enormous sympathy with the users, even though I suspect their case won't stand up in court).

Here's what I think happened to me (as best I can remember...I'm not about to try to reproduce it): Yeah, sure, look for my contacts (provide Gmail username/password...all assurances are given they won't email anyone without your permission blah blah). LinkedIn shows you a list of a few dozen (IIRC) contacts in a frame (possibly those you most recently exchanged email with?); I deselected all of those and then carefully went through and selected a very small subset I actually wanted to "connect to." Once I've done that, I hit submit (or whatever) and get some confirmation, "We're going to send the invite, okay?" Yeah, sure...it's only sending to a few people, right? SOMEWHERE on that confirmation (again, IIRC) is a checkbox that alludes to the fact that, oh? All the contacts you DIDN'T unselect--IN YOUR ENTIRE CONTACTS LIST--are gonna get an email. Got to the next screen and it said something like "200 emails sent" and the expletives flew. (I can see missing that message...it was small.) Of course I was doing this process while I was watching TV or something--it didn't have my full attention--but the behavior was SO counter to my expectations of opting-in I was floored.

I can see why users would think LinkedIn "stole their contacts when their email was left open"--they're thinking that subset-selecting frame is the only time LinkedIn is (transparently) accessing their account (and therefore shouldn't do anything with contacts that don't appear in that frame, which makes sense in terms of user expectation).