SkyDrive (formerly Windows Live Folders when it came out in August 2007) predates Google Drive by 5 years, Apples iCloud by 4 years and DropBox by a year. So how exactly is it a "me too" service?
Because Apple first introduced the iDisk in 2000.
(iDisk was part of iTools, which became
That's the catch. The standard Wireless Customer Agreement says that you can avoid the ETF if AT&T "increase[s] the price of any of the services to which you subscribe, beyond the limits set forth in your customer service summary" (emphasis added).
The Customer Service Summary (CSS) is the piece of paper that you get when you sign up, and is unique to you. You can download it from the online account.
The back page lists the estimated credits, adjustments, other charges, government fees and taxes. So you have no case as long as the fee actually imposed is less than the estimate in the CSS.
And guess what? My CSS from a year ago has a line item for "Other AT&T Surcharges" (for which there was no actual charge until now), and the estimated amount is higher than the new "Administrative" charge.
No wonder people who complain are told it isn't a breach of contract.
Further to this, AFAIK the only western country that taxes foreign income is the USA. If Apple was headquartered in any other country it could bring home foreign earnings free of extra taxation. So only the USA has this problem of it's companies keeping their money out of the home country.
Isn't that because the USA taxes income, while other countries use a Value Added Tax (VAT)?
If I read this correctly, the bug is still entirely on Apple's side as it chews CPU whenever any program using that API is running.
If that was true then why would it by fixed by installing an update to the other winsock LSP?
My guess is the other program was not implementing their LSP in full conformance to the API.
Parent is the most informative post in this entire topic.
There seems to be confusion about the Apple v. Microsoft lawsuits.
Microsoft won the 1988 to 1994 lawsuit over infringement of the GUI by Windows 2.0 and Windows 3.0, but Apple's case was hamstrung due to a licensing agreement for Windows 1.0. The court ruled that the vast majority of the infringement was covered by the licensing agreement, and the only remaining elements were not original to Apple.
The 2nd case was in 1997, when Apple alleged that Microsoft and Intel stole QuickTime code. Apple threatened Microsoft with a multi-billion dollar lawsuit and Microsoft threatened to cancel Office for Mac. They reached a settlement deal, with public announcement that Microsoft would continue Office development and buy $150 million of non-voting Apple stock. Oh, and there would be cross-licensing of patents.
It wasn't public knowledge at the time that the $150 million was really to settle the QuickTime theft, but the details came out in the 1998 US vs. Microsoft case.
I'm not ashamed to admit I liked Battlefield Earth, the book.
For one thing, it is a masterpiece of plotting. Before the end of the over 1,000 pages there are dozens and dozens of loose plot threads, and yet by the end every single one is neatly tied up.
COBOL also is very inexpressive and requires more lines of code to do the same thing
...unless you're doing the types of things COBOL was made for. Such as, dealing with fixed point numbers.
I have previously asked about creating sub-dirs on under the Application directory and people have warned me that doing will can break things and it is not worth the effort.
The issue is that some updater programs are expecting to be able to update the program in its original install location.
This is actually regression in OS X. In classic Mac OS, you can move an application anywhere or even rename it and it will still work. Don't like the Application folder organization? Change it!
In OS X, you should be wary of moving any of Apple's applications, since Apple's Software Update seems to be the one that is most guilty of making assumptions. Lately I've been leaving programs dropped by installers in their initial location. But if the "install" is simply dragging an icon from a disk image, you are free to put it in any folder you want.
OS X will automatically find applications in the Applications folder and in any subfolder, and also it scans applications when you click on them. After that, it knows everything it needs to about that application's existence. Usually application paths are not important, so it is OK to move an application, aside from the updater issue.
Another way to create your own "Start Menu" type organization is to create aliases to applications and organize the aliases anyway you want.
The rationalization for why Macs don't have a Start Menu and Window does, is you'd never want users to have to wade through the Program Files folders, since they contains so much more visible files than just the ones you're supposed to run. The Mac has always tried to keep the applications self-contained, so the Applications folder only contains the icons that are of use to the user. If you present the Applications folder as a menu hierarchy it is what would be in the Start menu.
So that's what Dr. Lizardo was doing.
Disk images as an Apple file distribution method originated back in Classic Mac days, all the way back to Disk Copy images in System 6. They are the native Mac version of an archive, which supports the same file meta data as the Mac file system.
It used to be that there were few alternatives that could safely transport files with resource forks: Stuffit Expander (.sit) and binhex encoded files (.hqx, which still required a third party program to decode).
Now Apple's implementation of
But Disk Images are still popular, because since they are a complete file system in a box, they support all of the same meta data as the source file system: Finder data (aka Finder flags), resource forks, extended attributes, everything.
Another advantage for file distribution is it creates a read-only package of files, rather than dump them all into the user's download folder. Consider if you are distributing an application plus optional files, and you want to give the user the ability to pick and choose what they copy to their Applications folder.
...If installed to the user directory it will not. That's why Chrome doesn't need admin rights - it's installed to C:\Users\[username]\Appdata\Local\Google by default.
Chrome is doing an end-around security rules that are designed to prevent applications from being installed without sufficient authority. In what way is this a good thing?
The U.S. has such a levy/tax on blank audio recording media, adopted as part of the Audio Home Recording Act of 1992.
The U.S. has such a levy/tax on blank digital audio recording media -- but today it essentially only apples to CD-R Audio discs, not ordinary CD-R discs. CD-R Audio discs would be used in consumer electronics audio recorders, which by law will reject recording on "computer" CD-R discs.
This method does not have the same effect as changing in the GUI. *
When you change an environment variable (including the PATH) in a command prompt, you only affect that command prompt. It doesn't change the parent Windows environment.
Try it: change the PATH in a command prompt, then open up a new command prompt and check the PATH -- your change won't be there.
There are non-GUI ways to change the Windows environment, including updating the PATH inside the Windows registry directly. But then the next trick is getting Windows to realize that the environment has changed and to notify the other tasks. This can be non-trivial.
* in Windows XP, at least
Heisenberg may have been here.
