Actually TFL answers this (and I suppose if the press uncovered any evidence to the contrary, then you can easily point us to it?):
Q: The seller of your house appears to be a doctor at the University of Chicago. Do you or your wife know him? If so, did either of you ever talk to him about subdividing the property? If you ever did discuss the property with him, when were those conversations?
A: We did not know him personally, though my wife worked in the same University hospital. The property was subdivided and two lots were separately listed when we first learned of it. We did not discuss the property with the owners; the sale was negotiated for us by our agent.
Q: How do you explain the fact your family purchased your home the same day as Rita Rezko bought the property adjacent to yours? Was this a coordinated purchase?
A: The sellers required the closing of both properties at the same time. As they were moving out of town, they wished to conclude the sale of both properties simultaneously. The lot was purchased first; with the purchase of the house on the adjacent lot, the closings could proceed and did, on the same day, pursuant to the condition set by the sellers.
APDFPR Error
The document was created with 'eBook Exchange (EBX_HANDLER) 128-bit security v.3' encryption handler. This protection method is not supported.
Yet I see some nicely decrypted ones floating around. E.g. (one of many for purely instructional purposes): ISBN 0387954775 here.
Having the eBook and the etx.etd file I guess that should in principle be possible, but how's that done in practice?
Another way to avoid this problem is to use the French version: "One can't have the butter and the butter's money [colloq.: and the dairymaid's ass on top]".
Re:Why is MacTech printing misinformation
on
iPods Don't Run OS X
·
· Score: 2, Informative
There's no indication that it's an April Fool's joke.
Funny you should ask that, I was just reading this (Steve Yegge, 26 Jun 2007):
I hope you're beginning to see, at least faintly, why I love working at Google. It's because the code base is clean. And anything that takes more than a week of effort requires a design document, with specific sections that have to be filled out, and with feedback from primary and secondary reviewers of your choice. The net result is that for any significant piece of code at Google, you can find almost a whole book about it internally, and a well-written one at that.
I've never seen anything like it before, to be honest. I don't think you can get that kind of software-engineering discipline without doing it right from the start, and creating a culture that enforces and reinforces that discipline as the organization grows.
Yeah, I kind of expected this reply, since of course the answers are a --version away for anyone with a beta build. That's why I specifically asked about anything said on the mailing lists, e.g. by Apple engineers, which I guess is then fair game to repeat. (I've seen that done before, those are not HUGE secrets; just didn't follow this time.)
if the package you want isn't the most up to date, Apple won't stop you installing it
Of course. It's more about what I can expect other people, who won't bother to use fink or macports, to have as the standard versions.
He got the part about Jon Johansen all wrong. Jon wasn't trying to defeat region coding. I don't like to see misinformation
I disagree.
I had the same reaction at first, so I re-read while keeping in mind that Doctorow probably knows better, and is phrasing things this way for a reason:
The DVD is your property and so is the DVD player, but if you
break the region-coding on your disc, you're going to run afoul
of anticircumvention.
That's what happened to Jon Johansen, a Norweigan teenager who
wanted to watch French DVDs on his Norweigan DVD player. He and
some pals wrote some code to break the CSS so that he could do
so.
(Alright, technically he should at least write Norwegian:) What he says is literally true -- it's just that Johansen's 'Norwegian DVD player' happened to be a Linux computer. Whether the impediment comes from geography or OS doesn't and shouldn't make a difference. Except for this: laymen can immediately relate to 'other country' but not to 'other OS'.
Getting a DVD to play on that 'Norwegian player' requires breaking the very same system that enforces region coding. (I should know, as I have to use VLC to watch the zone 2 DVD that I buy from Amazon.fr -- unless you think I should buy one laptop per region.) So what's the difference? You might say he's 'technically' misleading, but I think it's only fair considering that he's constantly up against the exact same tactic, to the N-th power.
He's not lying. At some point he's just got to level the field by using the same rhetorics as the opponent.
As a P.S. -- the sort of quote I had in mind, suggesting an affirmative answer is this:
assembly language programming is essential background for every computer science and electronic engineering student. It is, however, often considered an arcane and complex discipline because many first encounter it through the daunting instructions and registers of the Intel 8086 family.
Programming in a simple RISC architecture is very different due to the elegant and compact instruction set. Students of this text who have never programmed before and study it simultaneously with a course on a higher-level language report it is easier and more logical to program in assembly!
(referring unfortunately to an MIPS, not PPC book).
The first milestone I achieved was the release in the mid-1990s of the electronic edition of The Art of Assembly Language. This book, along with the use of the accompanying UCR Standard Library for 80x86 Language Programmers, reduced the effort needed to learn assembly language programming.
OK, is there (should there be?) anything like this for PowerPC assembly? I'm aware of these web pages:
IANAL, but was intrigued by this MacSlash post the other day. Can anyone familiar with the DMCA confirm whether or not it supports the claim made here? (emphasis mine)
The DMCA describes two categories of DRM: access control and copy control. It's illegal to distribute a product that can defeat either type of DRM.
There is, however, a big difference between those two types of DRM as far as DMCA is concerned. It's illegal to use a product that breaks access control, but DMCA does not prohibit you from using workarounds to make copies. That distinction exists in DMCA to preserve fair use.
Since the playfair program doesn't let you get around the access control (you still need an iTMS key) and it only allows you to make copies of files to which you have legitimately obtained access, it's legal to use it as long as you don't cross the fair use line.
if you put apps in the filesystem, people will have trouble finding them
No need to "put" Apps in the filesystem -- they already are in it. Especially in Unix, everything is a file, the system is file-centric. Overlaying an "application-centric" or "task-centric" paradigm means overlaying opaqueness, and creating the need for opaque tools to manage it.
Mac users have no trouble finding their Apps (usually right on their Desktop upon download, later wherever they felt like filing them, when they felt the need). Switchers have no trouble adapting to the Mac way.
Alright. Happy to see you drop the claim that Mac users "need to understand the concepts of installer package and app directories":)
Mac users might be comfortable with drag & drop and the filesystem hierarchy, but Windows users decidedly are not. Windows users make up the majority of computer users out there, and if we're going to do things to make it easier for converts, its better to target them.
I've watched Windows users, and patently, most of their problems stem from the fact that they never know where anything actually is. Instead they are constantly faced with "wizards" and opaque installers, black box after black box, "magic" designed to maintain them in a maximal state of ignorance and dependance.
Duplicating this nightmare of an interface is an error -- and I've yet to hear about any switcher having problems adapting to the Finder-style UI.
Think of that UI as the graphical equivalent of the Unix shell -- just the same, a unified, always-running environment that takes and pipes you commands, but graphically. Advocating instead the Windows train-wreck of wizards, "Start menus" and assorted toolbars is the equivalent of advocating DOS over the Unix shell, just because (at one point) "more people happen to be used to it".
Read this document on the Anti-Mac interface.
It was in my bookmarks. I think it's wrong. SQL-based file systems, WinFS and Storage are pie-in-the-sky vaporware. Google is a good interface to navigate a web that changes outside your control; not to manage your own hard drive, where you not only read but also write and execute stuff.
You dislike drag & drop? Fine... The Finder shell is not tied to it, it's not the only mode of interaction. Anything you can do with drag & drop you can also do through cut & paste, or double-click, or menu selection. The point of it is not to be based or depend on drag & drop, it's to provide a self-contained, consistent graphical equivalent of the shell.
Huh? You want php, so you find php in a list? Do you think people have trouble mapping from the food they want to order to a listing in a menu?
Yes, and Brad Griffiths in today's article agrees:
there needs to be a simple way for new users to install software. Projects like Synaptic Package Manager a step in the right direction, but they aren't perfect. Synaptic requires users to find and configure repositories and it doesn't use descriptive names for the packages it uses. I think one simple solution to this would be to divide packages between desktop applications and non-desktop applications.
And I agree with this last distinction: GUI apps should not install the same way as libraries and CLI programs. Apt-get php: fine. We agree on this and I already said so. But not Firefox or other user-launchable GUI apps. For those, app dir installation is miles better.
The Mac installer mechanism requires so many extra concepts. They need to understand the concept of an installer package,
No, they don't. They get an icon. Moving it moves the app, double-clicking it launches the app.
app directories,
No, they don't. It appears as one object in the GUI shell (a.k.a icon in the Finder). Completely intuitive. No need to know anything about its inner structure.
drag & drop (the majority of computer users do not understand that, because Windows doesn't use it very much),
So just because Windows is a broken GUI that doesn't understand drag & drop, any other system should give up on it? People lean to use Macs just fine.
and the filesystem.
Yes. Understanding the filesystem is a good thing. And in fact, they'll only need it when they want to (say) clean their desktop
Selecting an app in an APT GUI just requires knowing what app you want
That alone is complicated. You need to map "the app you want" to some name in a list. That's an entire parallel, cryptic, redundant hierarchy to understand and operate.
You double-click a program, and its installed and right in your programs menu.
The whole idea of an "Application menu" is an abomination, as is the parent "Start menu". It's duplicate information -- the root of all evil, isn't it? Once you start down that path, of course you'll need installers and package managers to keep things consistent.
App dirs and drag & drop installation define those problems out of existence. Each GUI application becomes one object in the GUI shell (a.k.a. Finder). Double-clicking it launches the app. Trashing it uninstalls the app. You put it wherever you want; you (not some opaque installer) make a shortcut to it elsewhere, if you want one.
(Of course it's fine to have installers for libraries and command line executables that are never launched from the GUI. Those can reside in hard coded locations where dependencies can find them.)
Slashdot Mirror
While Touretzky prefaces his page on the subject with "Computer professionals who have examined these mechanisms have found them easy to defeat", I miss something able to decrypt or print the latest crop -- where APDFPR says
Yet I see some nicely decrypted ones floating around. E.g. (one of many for purely instructional purposes): ISBN 0387954775 here.Having the eBook and the etx.etd file I guess that should in principle be possible, but how's that done in practice?
Ah, never mind.
Note the alleged output of ls -af (= ls --april --fool...):
Eran cheerfully edited Apr to Jul -- buying this hook, line and sinker, and now he whines that he was joking and misunderstood...
With that in mind I'd take a look at http://code.google.com/projects.html...
(Form cnn, "Estimate puts iPhone sales at 500,000 in opening weekend".)
So, I would expect that the 10.5 versions are already being tested in current builds, and that we'll be stuck with them for quite some time.
- apache
- bash
- ksh
- openssl
- perl
- postfix
- python
- ruby
- sqlite
- ssh
- svn (?)
- zsh
- x11
etc...?Correction: reappointed/elected.
...the new names of co-branded State Farm Insurance plans: bin Laden (Life), Arafat (Home Owner), Lady D. (Car), etc.
How is this flamebait? Has it been discussed before?
I disagree.
I had the same reaction at first, so I re-read while keeping in mind that Doctorow probably knows better, and is phrasing things this way for a reason:
(Alright, technically he should at least write NorwegianGetting a DVD to play on that 'Norwegian player' requires breaking the very same system that enforces region coding. (I should know, as I have to use VLC to watch the zone 2 DVD that I buy from Amazon.fr -- unless you think I should buy one laptop per region.) So what's the difference? You might say he's 'technically' misleading, but I think it's only fair considering that he's constantly up against the exact same tactic, to the N-th power.
He's not lying. At some point he's just got to level the field by using the same rhetorics as the opponent.
As a P.S. -- the sort of quote I had in mind, suggesting an affirmative answer is this:
(referring unfortunately to an MIPS, not PPC book).OK, is there (should there be?) anything like this for PowerPC assembly? I'm aware of these web pages:
Oh, the doublespeak. This ought to be really exposed.
No need to "put" Apps in the filesystem -- they already are in it. Especially in Unix, everything is a file, the system is file-centric. Overlaying an "application-centric" or "task-centric" paradigm means overlaying opaqueness, and creating the need for opaque tools to manage it.
Mac users have no trouble finding their Apps (usually right on their Desktop upon download, later wherever they felt like filing them, when they felt the need). Switchers have no trouble adapting to the Mac way.
Black-boxing everything = the Windows way.
Mac users might be comfortable with drag & drop and the filesystem hierarchy, but Windows users decidedly are not. Windows users make up the majority of computer users out there, and if we're going to do things to make it easier for converts, its better to target them.
I've watched Windows users, and patently, most of their problems stem from the fact that they never know where anything actually is. Instead they are constantly faced with "wizards" and opaque installers, black box after black box, "magic" designed to maintain them in a maximal state of ignorance and dependance.
Duplicating this nightmare of an interface is an error -- and I've yet to hear about any switcher having problems adapting to the Finder-style UI.
Think of that UI as the graphical equivalent of the Unix shell -- just the same, a unified, always-running environment that takes and pipes you commands, but graphically. Advocating instead the Windows train-wreck of wizards, "Start menus" and assorted toolbars is the equivalent of advocating DOS over the Unix shell, just because (at one point) "more people happen to be used to it".
Read this document on the Anti-Mac interface.
It was in my bookmarks. I think it's wrong. SQL-based file systems, WinFS and Storage are pie-in-the-sky vaporware. Google is a good interface to navigate a web that changes outside your control; not to manage your own hard drive, where you not only read but also write and execute stuff.
You dislike drag & drop? Fine... The Finder shell is not tied to it, it's not the only mode of interaction. Anything you can do with drag & drop you can also do through cut & paste, or double-click, or menu selection. The point of it is not to be based or depend on drag & drop, it's to provide a self-contained, consistent graphical equivalent of the shell.
Huh? You want php, so you find php in a list? Do you think people have trouble mapping from the food they want to order to a listing in a menu?
Yes, and Brad Griffiths in today's article agrees:
And I agree with this last distinction: GUI apps should not install the same way as libraries and CLI programs. Apt-get php: fine. We agree on this and I already said so. But not Firefox or other user-launchable GUI apps. For those, app dir installation is miles better.No, they don't. They get an icon. Moving it moves the app, double-clicking it launches the app.
app directories,
No, they don't. It appears as one object in the GUI shell (a.k.a icon in the Finder). Completely intuitive. No need to know anything about its inner structure.
drag & drop (the majority of computer users do not understand that, because Windows doesn't use it very much),
So just because Windows is a broken GUI that doesn't understand drag & drop, any other system should give up on it? People lean to use Macs just fine.
and the filesystem.
Yes. Understanding the filesystem is a good thing. And in fact, they'll only need it when they want to (say) clean their desktop
Selecting an app in an APT GUI just requires knowing what app you want
That alone is complicated. You need to map "the app you want" to some name in a list. That's an entire parallel, cryptic, redundant hierarchy to understand and operate.
The whole idea of an "Application menu" is an abomination, as is the parent "Start menu". It's duplicate information -- the root of all evil, isn't it? Once you start down that path, of course you'll need installers and package managers to keep things consistent.
App dirs and drag & drop installation define those problems out of existence. Each GUI application becomes one object in the GUI shell (a.k.a. Finder). Double-clicking it launches the app. Trashing it uninstalls the app. You put it wherever you want; you (not some opaque installer) make a shortcut to it elsewhere, if you want one.
(Of course it's fine to have installers for libraries and command line executables that are never launched from the GUI. Those can reside in hard coded locations where dependencies can find them.)