Numbers 5 and 6, as written, could clash with non-disclosure agreements & similar. For instance if I allow someone to inspect the code for my laboriously-written software for security purposes, I'd like to have a legally binding document with them stating that they're not allowed to hand over my source code to my competitors (or indeed anyone, unless they too sign the same agreement, etc.).
So do you pay for updates to those games, or do you get them for free?
For the updates you get for free, are those 100% bugfix updates, or do they include changes to functionality based on end users' feature requests?
Remember, the iPhone has little internal security. Every process runs with root privileges, so a program needs to have very strict boundaries.
Apps aren't run as root any more, and haven't been for some time now (update 1.1.1 ? 1.1.2 ?).
In addition, apps build for the SDK version of the iPhone (version 1.2 it would seem, judging by the version numbers of the 'Aspen' platform SDKs), will be run inside sandboxes, with their own Library, Documents, etc. folders. This means that they have very little chance of getting access to anything outside that sandbox; and of course anyone who tries could find their deployment certificate revoked. That ought to provide enough security for most people. Meanwhile, the iPhone Hacker crowd can continue doing exactly what they've been doing all along.
See, each customer base can do their own thing. Hackers can do what they do now, Joe Public can get games & apps which they like.
On the MP3 Players list, the iPod is doing really well.
On the Flash-based sub-list, the Sansa holds the top spot.
On the HDD-based sub-list, the Zune holds the top spot.
Now go back and look at that first list, and take note of the iPods in the top few places. Done that? Okay, your mission, should you choose to accept it, is to locate those same models on either of the other two lists.
No luck? Okay, just find *any* of the current generation of iPods (iPod Classic, iPod touch, iPod shuffle (clip version), iPod nano w/video) on the two narrowed lists. In fact, I don't see the new Zunes on those lists either, when it's apparently at #9 (at time of posting) on the general list. Nothing in the top 12 places on the general list appears in either of the other two.
So, it turns out there's a pretty simple explanation for this: Amazon hasn't tagged the latest generations of iPods or Zunes as either HDD- or flash-based.
As a result, they just don't show in those sub-lists. And since the price-dropped 1st Gen. Zune is proving more popular than last-season's iPods, it appears above them on all lists of which they are a member, including the general list (it's at #15 right now-- the 30Gb Brown one). It just happens to place behind all the current models from both manufacturers.
FSEvents was written primarily for the use of the time machine backupd process, which runs via launchd as a cron-like job every hour. They actually wrote FSEvents because, unlike the Spotlight daemon (which reads directly from/dev/fsevents) they didn't want the backup app to run constantly. FSEvents runs a constant background daemon for you, which simply builds up an aggregate log of everything it reads from the device.
Second, no WiFi. If it was a bit cheaper, or it had WiFi, at least your business customers might jump on the bandwagon.
You could do with checking the iPhone Product Page there. You'll notice that it does in fact boast WiFi support:
... you can read a web page while downloading your email in the background over Wi-Fi or EDGE.
I would imagine that the confusion here has arisen due to the lack of WiFi-based VoIP in the iPhone. But I'd expect that no carriers would agree to sell or work with the iPhone if it did cheap VoIP, so I had never given any credence to such rumours in the first place.
XServes are sweet, but they have some shortcomings too. They STILL don't offer dual power-supply or SAS--two of the best features of a wintel server I recently brought online at work.
Actually, that's incorrect these days -- at least as far as the XServe product page is concerned. And the online store reckons they can ship 'em in 24 hours, so it doesn't look like these are features for a product which isn't available yet.
A quick feature run-down:
Two dual-core 'Woodcrest' Xeon processors (64-bit, dual-core CPUs)
Support for up to 2.5TB of SATA or SAS storage
Support for dual redundant power supplies (a configuration option)
Hardware-wise, I think that's the main points -- although I've not really had experience with them (my exposure to OS X Server has been a case of installing it on a bunch of regular G3 & G4 Macs for use as AFP/LDAP servers for client software testing). Feel free to call me out on anything I've missed which you'd deem important.
Actually, aliases are designed to try to cover all bases.
An alias can be created in either full or minimal forms. The exact internal makeup is something I've not had the need to really go into, but for example a minimal alias will contain the current path for the item and that item's file number in the volume catalog, and also something describing which volume it's on (a volume number perhaps, but not enough information to go and mount that volume if it's not already available). A full alias can also contain enough information to go & connect to a shared resource for you.
Generally, the alias resolution will involve checking the encoded path to see if the item is still there (or if it's been replaced), then looking for the file number. A full alias can also contain some further search criteria which would be useful in locating an atomically-swapped file (overwrite A by writing B then deleting A and renaming B to A) which has later had a separate name change. In the network case, it can make use of a URL to determine some means of mounting the network volume containing the target file, such that double-clicking the alias will cause a server logon (unless the password has been saved in your keychain, or unless you have a Kerberos ticket) to appear, requesting a password. It'll then proceed to mount the volume and open the target item.
The problem you've described regarding renamed old versions of files is usually solved by resolving based on path/URL first, before looking at the File ID. Things like being able to create an alias which will mount a shared volume for you, and aliasing files which you might personally move from one folder to another (by archiving to an 'old projects' folder, perhaps) are usually deemed important enough to make aliases useful. Especially when those aliases point to an application somewhere: drag Calculator to your Dock. Then drag the app onto your desktop. Click the icon in the Dock and it still launches -- this is because the Dock will use FSNewAliasMinimal() to record the location of the item, along with its URL (a hangover from the NeXTStep days I believe).
Yahoo is offering free push email to ALL iPhone customers--couldn't he have used.mac?
Y'know, I thought that too. But after a while, I had the following revelation:
I receive perhaps 40 or so emails per day through my (relatively spam-free).mac account. Most of those are from mailing lists I've signed up to. When those mailing lists are busy, I can receive well over a hundred, hundred-and-fifty emails per day there.
I really don't want all those making my phone go 'bing' every five minutes.
Of course, that's not to say that we couldn't have free.mac push email anyway, as an added feature for.mac subscribers with an iPhone: it could be simple, tied to an alias (all emails sent to the alias account me_iphone@mac.com get pushed, as well as being delivered to the real 'me@mac.com' IMAP inbox in the usual fashion). It could be rules-based, setup online: everything marked urgent, not suspected to be spam, or sent by someone in my address book (or by someone on a specific list).
One of the things to remember, though, is that not everyone who buys an iPhone wants a.mac account. And of course if push email was only available through the purchase of a.mac account, you can bet that there would have been a lot of complaints about that 'hidden cost'
The first type is the standard, and has been as long as I've been alive (thirty years on Monday, dear god that's depressing). It's used for pretty much everything, and anything which doesn't want to use a real ground pin has to demonstrate that it's shielded and wouldn't need it in the first place.
The second type is normally used to attach things to the lighting circuit, so you can rewire your floor lamps & table lamps, such that they'll all be switched on or off by the light switch on the wall. My parents do this, for example: one switch for the overhead light, one for the four lamps positioned around the room.
The two-pin European-style plug is used in bathrooms, where standard voltage uninsulated equipment is not allowed (i.e. a contractor isn't allowed to put standard sockets in a bathroom, or in other areas where they may be lots of water). They'll usually have a badge on them describing how they're only for razors, and only 110v. Frequently it'll also be attached to some form of light circuit too, usually on a strip flourescent light.
Of course, you could wire up your house to use whichever you like. But the standard is the three-square-pin, and has been for a very long time. The different shapes are usually used to designate whether a socket is for the ring main (square), lighting loop (round), or double-insulated razor-type device near exposure to water (round pair, low voltage).
Please tell me that's sarcasm. I can already hear the footsteps of all the 'iTunes is teh evil DRM' trolls thundering over to agree... *shudders*
I mean, sure they're funny to watch, kinda like that little kitten that's so determined that it's going to catch you and drag you off by your ankle. At some point, though, you start to feel like you really ought to just put them out of their misery-- after all, they can't really be happy like that, can they?
-Q (whose iTunes library, incidentally, contains only four or five albums from the iTMS)
Because in most applications, you usually use the tab key to move between the text fields in ordeer to quickly type in some values, then press enter or escape to continue. As such, the default functionality is to move between text boxes and lists.
It is possible to do it though: In System Preferences, go to 'Keyboard & Mouse', then the 'Keyboard Shortcuts' tab. There are options down the bottom for full keyboard access. Also, if you look through the shortcut list in that same panel, you'll see that there's a bunch of keyboard shortcuts designed for further keyboard navigation, inclidung:
Turn full keyboard access on/off: ^F1
Move keyboard focus to the menu bar: ^F2
Move keyboard focus to the dock: ^F3
and so on
While generally I agree with the current design, I think it would be appropriate to have a separate setting there just for use in web forms, perhaps. However, since the root of the functionality is embedded inside the App Kit, I don't really expect that to happen.
Until then, there's the Full Keyboard Access thing, or in Safari you can use Option-Tab, which (by default) will take you to the next activate-able item on the current page (including links, etc.) Having just tried it now, however, it seems not to want to jump out of large text boxes (like the one I'm typing this in), so I had to plain-tab (to the format pulldown menu), then shift-option-tab back to the karna/anonymous checkboxes. The setting for this (it can be made the default 'tab' action) is in the Advanced pref pane within Safari.
AFP doesn't seem to lock up OS X every time a share goes missing--especially annoying on a laptop that goes in and out of network range--and freebsd's support of it is just peachy in my book.
Yep, sounds about right; AFP uses a keepalive 'tickle' system to determine whether the other end of the connection is there. Usually a tickle packet (16 bytes) is sent from server to client about once every 30 seconds, and the client will either do the same or (more usually) send one back every time it receives one. There are some timeouts (I think 60 seconds or 120 seconds, depending on whether one side is expecting data from the other) where if one end doesn't receive a tickle during that time, it assumes the connection has gone down.
The nice thing in AFP 3 (introduced in OS X) is that on top of this they added protocol support for reconnects. So you can have your connection drop and choose not to automatically disconnect (although you won't be able to access the volume -- may hit timeouts if you try), and when the connection is once more available it will re-establish a connection and quite possibly get back the same session you had before, complete with opened files and suchlike. It also has nice sleep support, but that's not very new (been around since AFP 2.3) -- a client can tell the server it's going to sleep, and that basically sets the server's no-tickle-disconnect timeout to 24 hours.
Nope. It's a separate protocol which historically used AppleTalk (ATP) as its transmission protocol. Now it uses TCP.
Back in the day, an AppleTalk installation was a whole software stack which included AppleTalk and all sorts of other things. For instasnce, following the example of AFP circa 1990, we see the following stack, each item using the services published by the item directly below:
AppleTalk Filing Protocol (AFP)
AppleTalk Session Protocol (ASP)
AppleTalk Transaction Protocol (ATP)
Datagram Delivery Protocol (DDP)
Off to the side of this (above DDP) is Name Binding Protocol (NBP) which is used to look up services by name (this is what ZeroConf/Bonjour is implementing over IP).
Since sometime in System 7 or Mac OS 8 (a good ten years, IIRC), AFP has also had another optional equivalent stack available to it:
Apple Filing Protocol (AFP)
Data Stream Interface (DSI)
Transmission Control Protocol (TCP)
Internet Protocol (IP)
The TCP & IP items there you'll recognise, but DSI is a new one -- it essentially implements a 16-byte header similar to the one used by ASP back in the day, which AFP then uses to indicate whether it's asking for a new connection, closing a connection, whether a packet is a request or a reply, which packet ID it has (or is replying to), the length of thje AFP command following, and any error code returned from the server. The AFP packet format itself is unchanged, except that TCP/IP allows larger packet/datagram sizes than AppleTalk, so the WriteContinue ASP command has been done away with, since the whole lot can be sent via TCP/IP in a single (potentially massive) DSI/AFP packet.
In Mac OS X, AppleTalk is there, but usually not enabled by default (go to System Preferences->Network->[Device]->AppleTalk -- you'll see the checkbox is likely unchecked, at least if this is a recent installation rather than an upgrade from c. OS X 10.2). AFP will work over AppleTalk if it has to (talking to old machines that don't do AFP over TCP), although it will always prefer TCP/IP. In point of fact, on Mac OS X it'll likely be using IPv6 for local-area networking, since all OS X machines sort out link-local IPv6 addresses for themselves, and all OS X AFP server process advertise those addresses too.
Also:
Can't go wrong with using SMB for your local network.
Yes you can. I've spoken to people at large institutions who have their Macs mounting network home folders. Frequently when those home folders are mounted using SMB, they find that applications such as Microsoft Office can have trouble auto-saving (in some cases, any sort of saving) to those volumes. There are incompatibilities, because Mac apps tend to assume that all the Mac filesystem metadata exists, and is atomically writable along with the file itself (not stored in a separate hidden file elsewhere). Some of these apps then try to be too clever when locking/updating/unlocking files, and run into trouble.
Long story short: If you're using Macs, share using AFP wherever possible. AFP supports everything HFS supports. SMB doesn't. SMB support on the Mac is mostly there to facilititate moving files between Macs & Windows machines. You can use NFS for Linux/Unix if you want, and you can (and should) use AFP for Mac-to-Mac networking. Things will go more smoothly if you do.
So if I get a Core2Duo Mac with a good video card, and boot into Windows, will it run my games as well as a similarly configured PC? I really would like to switch over to Mac, but I've gotta be able to run a few Windows programs (games and Sonar, mainly).
In a word: yes.
Of course, pick a model with plenty of VRAM, bump the RAM up to 1Gb or more. I have a 17" original Intel iMac here with the stock 128Mb X1600 and a 1.83GHz Core Duo, and it does HL2 nicely enough for me. I also have Oblivion, NWN, NWN2, and the latest Tomb Raider on here; I can't really max out the settings in Oblivion or Tomb Raider, but that's largely due to my limited VRAM (damn, I remember when 12Mb VRAM was considered a lot).
Bottom line is: something like an iMac won't ever be a blinged-out gaming monster, but that's not what it's designed for. A Mac Pro with switchable graphics cards would be more the sort of thing you'd want there. But certainly Windows runs well enough on the Mac to make it useful for games.
Given that it is highly doubtful that there is an Intel processor inside the iPhone, it will mean recompilation to run on the CPU that is in there. Honestly, given the form factor, it's much like trying to take a Win32 application to CE or vice versa - it doesn't work. Not because you can't scrape or expand the API to fit one another, it's just a totally different UI paradigm.
It's worth remembering that Xcode already has cross-platform compilation built in via gcc, and that likely the APIs used for user-level applications will be Objective-C, which shields programmers from a lot of low-level stuff. ObjC's message-passing even insulates developers from things like function-call ABIs to a large extent. Don't forget that OS X is based on NeXTStep & OpenStep, which (just like the PPC/Intel 'universal binaries') were able to recompile/bundle applications to run on multiple processors. Unless you're doing something fairly close-to-the-metal, writing apps via the Cocoa framework (and probably a separate ObjC iPhone framework) will likely mean that compilation is just a couple of clicks away -- and it'll build an Intel/PPC version for local debugging, and an (ARM? PPC? etc?) for deployment/final testing.
As for the differing UI, it's not all that difficult to change an app to match that -- after all, we're talking about a somewhat slimmed-down device -- because it would use the same standard high-level view, control, and layout code. While something like Delicious Library might have some potential for an iPhone application, it wouldn't look exactly the same, because the current UI for it has been designed -- by the app's developers -- according to a larger available screen. For something with a small screen, it could be tweaked to have each view appear in sequence, like the iPod menus & the iPhone mail application: List of libraries, contents of library (even with the cover browser UI), and select an item to view details. But being Objective-C, it likely wouldn't need a vast deal of changes beyond that; the code for each view might well be exactly the same. Certainly the item information view probably needn't change, nor the library list. The cover/shelf view might need tweaking to optimize it for smaller displays -- then again even that might not be necessary.
Then again, we may be restricted to HTML/Javascript 'widgets' -- who knows?
I'd have to say that I agree, this doesn't sound 'bad' to me, although I'll admit I haven't read the full details. But a watermark is the perfect 'DRM', I'd say. No actual restrictions on what you can do, but if the authorities find pirate DVDs sold from a market stall at $2 apiece, or liberally distributed online, they are able to track down the originator through the watermark. Meanwhile, other people who aren't making copies to sell for profit or otherwise distribute (i.e. are only interested in exercising their fair-use rights) aren't impeded in any way, but can still make as many copies as they want, in whichever media they so choose.
To attempt an analogy, I'd have no problems with my copied media including a watermark identifying me as the source, in exactly the same way that I have no problem with having license plates traceable to me on my car. I'm not intending to do anything illegal with either, so I'm happy to attach my identity to it.
No, if I want to know what my IP address is, I run the application called "Network Utility". It doesn't get any more intuitive than that.
Sure it does -- on my Macs, I just open Sys Prefs, goto 'Network', and when I pick an interface (like, say, the topmost one with a green 'active' light), then I can see my IP address. And the important thing here (to me) is that I can see my IP even if I'm using DHCP. One thing which always annoys the crap out of me on XP is that the IP dialog (which takes a few clicks & modal dialogs to reach) has the option to either enter the IP or use DHCP, and if you use DHCP, the IP address field is not filled out (un-editably) with the obtained address. In this case, you have to go to the DOS prompt & use 'ipconfig'. Or at least, I've not found anything simpler for that.
Point being, I don't think it's at all clear that telecoms can't start throttling traffic *now*, if they so choose. And hence Google's (and others) efforts to get legislation passed to *prevent* this from happening. Last I'd heard, anyway.
In my understanding, this is essentially correct-- the technology to do this exists now. However, they can be sued for this discrimination. Under the new laws being written, there is no explicit prohibition on this activity, so activists in favour of Net Neutrality would like these prohibitions to be made explicit in the new laws. This is because there's a difference between seeking sanctions against someone who has obviously performed an action counter to the written laws, and seeking sanctions against a company who you stipulate has done some against the presumed spirit of the law. It's the difference between getting sanctions against Comcast via the federal rules under which Comcast operates its (limited) monopoly, and going after them using anti-trust law.
Essentially, there are ways and means for these common carriers to be stopped, legally, from doing this sort of thing. The new rules (new in that they apply to the Internet, I believe, wheras the current rules apply to all forms of communication) do not have that provision, thus essentially making the Internet an area where common carriers can behave in that manner. There is great opposition to this, because the CCs would have us believe that it'll stop them using any QoS at all, and that they wouldn't be able to provide tiered service, etc. However, when you consider that we simply want the competition rules from the existing legislation placed into this new Internet-specific legislation, one has to wonder how it will create restrictions: they are the same rules they're following now.
Another poster put it quite well: at the moment, they aren't allowed to prioritize traffic based on source. They can prioritize different *types* of traffic, but they aren't allowed to (for example) give their own video/VoIP traffic better throughput than their competitors. So, AT&T can give VoIP high priority, but they must do so for everyone; they are not allowed to give their own VoIP high priority while leaving Vonage customers with standard or low priority. This is how it works now, with the existing legislation. The new stuff doesn't explicitly say that, and, given the comments made by folks at Comcast & others, we feel it is unsafe to leave these rules un-codified, because we believe the little buggers will take advantage of that situation.
The thing most folks are concerned with is the ability for a network provider to request money from someone with whom they currently have no business relationship, and to penalize anyone who doesn't pay up. Here's an example:
Let's assume the that Google leases its internet connection from Bell, and that there are a large number of consumers using AT&T DSL service to access Google.
So, AT&T looks at its traffic, and realises that they are routing a lot of traffic from their customers to Google, and routing the replies back again. They send someone to Google, asking for money. Google tells AT&T that it already pays some ridiculous amount of money for its internet connection (say, $250'000 per month), and is not going to pay AT&T. Neither will it pay Comcast or Rogers, who over the last week have also asked for large amounts of money.
AT&T (and Comcast, and Rogers) go back to their HQ and tune their Quality-of-Service so that Google's traffic is slowed down significantly. Now only Bell customers can access Google at the speeds for which Google is paying 3 million dollars a year.
Now, the government is currently trying to enact legislation which will make the above possible. The supporters of the Net Neutrality movement argue that the rules should stay as they are: we've not needed explicit rules before, we shouldn't be adding them now. The opponents of the movement argue that network companies shouldn't be stopped from using Quality-of-Service in their offerings. Now, there were some important points there:
Firstly, the existing legislation is effectively in favour of Net Neutrality; it doesn't grant any privileges which aren't intrinsic to the operation of the system as a whole. There is new legislation being created which changes that, however, and that new legislation is what people are trying to get rid of, to keep the existing level playing field.
Secondly, you see the argument that Net Neutrality shouldn't be allowed because then Bell won't be able to charge more for higher bandwidth, or for better quality of service, and so on. This is a red herring, however: Net Neutrality supporters don't much care about that. We don't expect that everything will cost the same. It's perfectly acceptable to us that any consumer -- be they private or corporate -- desiring higher access speeds or better quality of service would pay extra for that. It's a service, you pay for it. That's fine. What we don't like is the way that a company like AT&T or Comcast could potentially charge money from any company whose data crosses their network at any point.
So, if an AT&T customer uses Google, they would ask Google for money. The AT&T customer is already paying them, and is getting exactly what they paid for. Google is paying their provider, and getting what they paid for. Some network providers, however, believe that data crossing their network is not being paid for, and so should be able to request reimbursement from the content providers. At which point one might well ask: What are the consumers of AT&T's home DSL service paying for, if not for their traffic to be routed across AT&T's network?
The arguments come thick & fast, but it ultimately comes down to something similar to that employed by Universal against the iPod and (successfully) the Zune: These people make money by selling something which works alongside our product. Even though we're paid for our product, we want money from the device our product works with, because without our product, the device couldn't function.
So, I hope this clears things up for you: charging your customers extra for better QoS is not a problem. Charging people who aren't your customers for QoS -- or explicitly lowering QoS for companies who don't hand you money -- is not. We're not asking the government to create rules disallowing it, we'd just like the new rules enabling that behaviour to be removed please, or at least re
Slashdot Mirror
Numbers 5 and 6, as written, could clash with non-disclosure agreements & similar. For instance if I allow someone to inspect the code for my laboriously-written software for security purposes, I'd like to have a legally binding document with them stating that they're not allowed to hand over my source code to my competitors (or indeed anyone, unless they too sign the same agreement, etc.).
Japanese Americans 1942
That should provide a little context as to the enforcement of the bill of rights. Thanks to George Carlin for reminding me of this one.
So do you pay for updates to those games, or do you get them for free?
For the updates you get for free, are those 100% bugfix updates, or do they include changes to functionality based on end users' feature requests?
If it's all about ensuring aging performers (who can no longer physically perform) continue to make money, that's fine.
Just set a required minimum royalty rate of 50% on all copyrighted works more than 50 years old.
That shouldn't be a problem, right? I mean, this is being done for the performers, isn't it?
OS/X? Is this the super-secret IBM version of Mac OS X?
-Q
Oh, and PS: No.
Remember, the iPhone has little internal security. Every process runs with root privileges, so a program needs to have very strict boundaries.
Apps aren't run as root any more, and haven't been for some time now (update 1.1.1 ? 1.1.2 ?).
In addition, apps build for the SDK version of the iPhone (version 1.2 it would seem, judging by the version numbers of the 'Aspen' platform SDKs), will be run inside sandboxes, with their own Library, Documents, etc. folders. This means that they have very little chance of getting access to anything outside that sandbox; and of course anyone who tries could find their deployment certificate revoked. That ought to provide enough security for most people. Meanwhile, the iPhone Hacker crowd can continue doing exactly what they've been doing all along.
See, each customer base can do their own thing. Hackers can do what they do now, Joe Public can get games & apps which they like.
-Q
'iPod classic' is the new name for the HDD-based iPods. It's basically a 6G iPod, and was first released a couple months ago.
-Q
Okay, here's something interesting:
Now go back and look at that first list, and take note of the iPods in the top few places. Done that? Okay, your mission, should you choose to accept it, is to locate those same models on either of the other two lists.
No luck? Okay, just find *any* of the current generation of iPods (iPod Classic, iPod touch, iPod shuffle (clip version), iPod nano w/video) on the two narrowed lists. In fact, I don't see the new Zunes on those lists either, when it's apparently at #9 (at time of posting) on the general list. Nothing in the top 12 places on the general list appears in either of the other two.
So, it turns out there's a pretty simple explanation for this:
Amazon hasn't tagged the latest generations of iPods or Zunes as either HDD- or flash-based.
As a result, they just don't show in those sub-lists. And since the price-dropped 1st Gen. Zune is proving more popular than last-season's iPods, it appears above them on all lists of which they are a member, including the general list (it's at #15 right now-- the 30Gb Brown one). It just happens to place behind all the current models from both manufacturers.
-Q
FSEvents was written primarily for the use of the time machine backupd process, which runs via launchd as a cron-like job every hour. They actually wrote FSEvents because, unlike the Spotlight daemon (which reads directly from /dev/fsevents) they didn't want the backup app to run constantly. FSEvents runs a constant background daemon for you, which simply builds up an aggregate log of everything it reads from the device.
You could do with checking the iPhone Product Page there. You'll notice that it does in fact boast WiFi support:
I would imagine that the confusion here has arisen due to the lack of WiFi-based VoIP in the iPhone. But I'd expect that no carriers would agree to sell or work with the iPhone if it did cheap VoIP, so I had never given any credence to such rumours in the first place.
*shrugs*
-Q
Actually, that's incorrect these days -- at least as far as the XServe product page is concerned. And the online store reckons they can ship 'em in 24 hours, so it doesn't look like these are features for a product which isn't available yet.
A quick feature run-down:
Hardware-wise, I think that's the main points -- although I've not really had experience with them (my exposure to OS X Server has been a case of installing it on a bunch of regular G3 & G4 Macs for use as AFP/LDAP servers for client software testing). Feel free to call me out on anything I've missed which you'd deem important.
-Q
Actually, aliases are designed to try to cover all bases.
An alias can be created in either full or minimal forms. The exact internal makeup is something I've not had the need to really go into, but for example a minimal alias will contain the current path for the item and that item's file number in the volume catalog, and also something describing which volume it's on (a volume number perhaps, but not enough information to go and mount that volume if it's not already available). A full alias can also contain enough information to go & connect to a shared resource for you.
Generally, the alias resolution will involve checking the encoded path to see if the item is still there (or if it's been replaced), then looking for the file number. A full alias can also contain some further search criteria which would be useful in locating an atomically-swapped file (overwrite A by writing B then deleting A and renaming B to A) which has later had a separate name change. In the network case, it can make use of a URL to determine some means of mounting the network volume containing the target file, such that double-clicking the alias will cause a server logon (unless the password has been saved in your keychain, or unless you have a Kerberos ticket) to appear, requesting a password. It'll then proceed to mount the volume and open the target item.
The problem you've described regarding renamed old versions of files is usually solved by resolving based on path/URL first, before looking at the File ID. Things like being able to create an alias which will mount a shared volume for you, and aliasing files which you might personally move from one folder to another (by archiving to an 'old projects' folder, perhaps) are usually deemed important enough to make aliases useful. Especially when those aliases point to an application somewhere: drag Calculator to your Dock. Then drag the app onto your desktop. Click the icon in the Dock and it still launches -- this is because the Dock will use FSNewAliasMinimal() to record the location of the item, along with its URL (a hangover from the NeXTStep days I believe).
-Q
Y'know, I thought that too. But after a while, I had the following revelation:
I receive perhaps 40 or so emails per day through my (relatively spam-free) .mac account. Most of those are from mailing lists I've signed up to. When those mailing lists are busy, I can receive well over a hundred, hundred-and-fifty emails per day there.
I really don't want all those making my phone go 'bing' every five minutes.
Of course, that's not to say that we couldn't have free .mac push email anyway, as an added feature for .mac subscribers with an iPhone: it could be simple, tied to an alias (all emails sent to the alias account me_iphone@mac.com get pushed, as well as being delivered to the real 'me@mac.com' IMAP inbox in the usual fashion). It could be rules-based, setup online: everything marked urgent, not suspected to be spam, or sent by someone in my address book (or by someone on a specific list).
One of the things to remember, though, is that not everyone who buys an iPhone wants a .mac account. And of course if push email was only available through the purchase of a .mac account, you can bet that there would have been a lot of complaints about that 'hidden cost'
-Q
The first type is the standard, and has been as long as I've been alive (thirty years on Monday, dear god that's depressing). It's used for pretty much everything, and anything which doesn't want to use a real ground pin has to demonstrate that it's shielded and wouldn't need it in the first place.
The second type is normally used to attach things to the lighting circuit, so you can rewire your floor lamps & table lamps, such that they'll all be switched on or off by the light switch on the wall. My parents do this, for example: one switch for the overhead light, one for the four lamps positioned around the room.
The two-pin European-style plug is used in bathrooms, where standard voltage uninsulated equipment is not allowed (i.e. a contractor isn't allowed to put standard sockets in a bathroom, or in other areas where they may be lots of water). They'll usually have a badge on them describing how they're only for razors, and only 110v. Frequently it'll also be attached to some form of light circuit too, usually on a strip flourescent light.
Of course, you could wire up your house to use whichever you like. But the standard is the three-square-pin, and has been for a very long time. The different shapes are usually used to designate whether a socket is for the ring main (square), lighting loop (round), or double-insulated razor-type device near exposure to water (round pair, low voltage).
-Q
Please tell me that's sarcasm. I can already hear the footsteps of all the 'iTunes is teh evil DRM' trolls thundering over to agree ... *shudders*
I mean, sure they're funny to watch, kinda like that little kitten that's so determined that it's going to catch you and drag you off by your ankle. At some point, though, you start to feel like you really ought to just put them out of their misery-- after all, they can't really be happy like that, can they?
-Q (whose iTunes library, incidentally, contains only four or five albums from the iTMS)
Because in most applications, you usually use the tab key to move between the text fields in ordeer to quickly type in some values, then press enter or escape to continue. As such, the default functionality is to move between text boxes and lists.
It is possible to do it though: In System Preferences, go to 'Keyboard & Mouse', then the 'Keyboard Shortcuts' tab. There are options down the bottom for full keyboard access. Also, if you look through the shortcut list in that same panel, you'll see that there's a bunch of keyboard shortcuts designed for further keyboard navigation, inclidung:
While generally I agree with the current design, I think it would be appropriate to have a separate setting there just for use in web forms, perhaps. However, since the root of the functionality is embedded inside the App Kit, I don't really expect that to happen.
Until then, there's the Full Keyboard Access thing, or in Safari you can use Option-Tab, which (by default) will take you to the next activate-able item on the current page (including links, etc.) Having just tried it now, however, it seems not to want to jump out of large text boxes (like the one I'm typing this in), so I had to plain-tab (to the format pulldown menu), then shift-option-tab back to the karna/anonymous checkboxes. The setting for this (it can be made the default 'tab' action) is in the Advanced pref pane within Safari.
Hope this helps,
-Q
Yep, sounds about right; AFP uses a keepalive 'tickle' system to determine whether the other end of the connection is there. Usually a tickle packet (16 bytes) is sent from server to client about once every 30 seconds, and the client will either do the same or (more usually) send one back every time it receives one. There are some timeouts (I think 60 seconds or 120 seconds, depending on whether one side is expecting data from the other) where if one end doesn't receive a tickle during that time, it assumes the connection has gone down.
The nice thing in AFP 3 (introduced in OS X) is that on top of this they added protocol support for reconnects. So you can have your connection drop and choose not to automatically disconnect (although you won't be able to access the volume -- may hit timeouts if you try), and when the connection is once more available it will re-establish a connection and quite possibly get back the same session you had before, complete with opened files and suchlike. It also has nice sleep support, but that's not very new (been around since AFP 2.3) -- a client can tell the server it's going to sleep, and that basically sets the server's no-tickle-disconnect timeout to 24 hours.
-Q
Heh... can you tell I do this for a living? ;o)
Nope. It's a separate protocol which historically used AppleTalk (ATP) as its transmission protocol. Now it uses TCP.
Back in the day, an AppleTalk installation was a whole software stack which included AppleTalk and all sorts of other things. For instasnce, following the example of AFP circa 1990, we see the following stack, each item using the services published by the item directly below:
- AppleTalk Filing Protocol (AFP)
- AppleTalk Session Protocol (ASP)
- AppleTalk Transaction Protocol (ATP)
- Datagram Delivery Protocol (DDP)
Off to the side of this (above DDP) is Name Binding Protocol (NBP) which is used to look up services by name (this is what ZeroConf/Bonjour is implementing over IP).Since sometime in System 7 or Mac OS 8 (a good ten years, IIRC), AFP has also had another optional equivalent stack available to it:
- Apple Filing Protocol (AFP)
- Data Stream Interface (DSI)
- Transmission Control Protocol (TCP)
- Internet Protocol (IP)
The TCP & IP items there you'll recognise, but DSI is a new one -- it essentially implements a 16-byte header similar to the one used by ASP back in the day, which AFP then uses to indicate whether it's asking for a new connection, closing a connection, whether a packet is a request or a reply, which packet ID it has (or is replying to), the length of thje AFP command following, and any error code returned from the server. The AFP packet format itself is unchanged, except that TCP/IP allows larger packet/datagram sizes than AppleTalk, so the WriteContinue ASP command has been done away with, since the whole lot can be sent via TCP/IP in a single (potentially massive) DSI/AFP packet.In Mac OS X, AppleTalk is there, but usually not enabled by default (go to System Preferences->Network->[Device]->AppleTalk -- you'll see the checkbox is likely unchecked, at least if this is a recent installation rather than an upgrade from c. OS X 10.2). AFP will work over AppleTalk if it has to (talking to old machines that don't do AFP over TCP), although it will always prefer TCP/IP. In point of fact, on Mac OS X it'll likely be using IPv6 for local-area networking, since all OS X machines sort out link-local IPv6 addresses for themselves, and all OS X AFP server process advertise those addresses too.
Also:
Can't go wrong with using SMB for your local network.Yes you can. I've spoken to people at large institutions who have their Macs mounting network home folders. Frequently when those home folders are mounted using SMB, they find that applications such as Microsoft Office can have trouble auto-saving (in some cases, any sort of saving) to those volumes. There are incompatibilities, because Mac apps tend to assume that all the Mac filesystem metadata exists, and is atomically writable along with the file itself (not stored in a separate hidden file elsewhere). Some of these apps then try to be too clever when locking/updating/unlocking files, and run into trouble.
Long story short: If you're using Macs, share using AFP wherever possible. AFP supports everything HFS supports. SMB doesn't. SMB support on the Mac is mostly there to facilititate moving files between Macs & Windows machines. You can use NFS for Linux/Unix if you want, and you can (and should) use AFP for Mac-to-Mac networking. Things will go more smoothly if you do.
-Q
In a word: yes.
Of course, pick a model with plenty of VRAM, bump the RAM up to 1Gb or more. I have a 17" original Intel iMac here with the stock 128Mb X1600 and a 1.83GHz Core Duo, and it does HL2 nicely enough for me. I also have Oblivion, NWN, NWN2, and the latest Tomb Raider on here; I can't really max out the settings in Oblivion or Tomb Raider, but that's largely due to my limited VRAM (damn, I remember when 12Mb VRAM was considered a lot).
Bottom line is: something like an iMac won't ever be a blinged-out gaming monster, but that's not what it's designed for. A Mac Pro with switchable graphics cards would be more the sort of thing you'd want there. But certainly Windows runs well enough on the Mac to make it useful for games.
-Q
It's worth remembering that Xcode already has cross-platform compilation built in via gcc, and that likely the APIs used for user-level applications will be Objective-C, which shields programmers from a lot of low-level stuff. ObjC's message-passing even insulates developers from things like function-call ABIs to a large extent. Don't forget that OS X is based on NeXTStep & OpenStep, which (just like the PPC/Intel 'universal binaries') were able to recompile/bundle applications to run on multiple processors. Unless you're doing something fairly close-to-the-metal, writing apps via the Cocoa framework (and probably a separate ObjC iPhone framework) will likely mean that compilation is just a couple of clicks away -- and it'll build an Intel/PPC version for local debugging, and an (ARM? PPC? etc?) for deployment/final testing.
As for the differing UI, it's not all that difficult to change an app to match that -- after all, we're talking about a somewhat slimmed-down device -- because it would use the same standard high-level view, control, and layout code. While something like Delicious Library might have some potential for an iPhone application, it wouldn't look exactly the same, because the current UI for it has been designed -- by the app's developers -- according to a larger available screen. For something with a small screen, it could be tweaked to have each view appear in sequence, like the iPod menus & the iPhone mail application: List of libraries, contents of library (even with the cover browser UI), and select an item to view details. But being Objective-C, it likely wouldn't need a vast deal of changes beyond that; the code for each view might well be exactly the same. Certainly the item information view probably needn't change, nor the library list. The cover/shelf view might need tweaking to optimize it for smaller displays -- then again even that might not be necessary.
Then again, we may be restricted to HTML/Javascript 'widgets' -- who knows?
-Q
I'd have to say that I agree, this doesn't sound 'bad' to me, although I'll admit I haven't read the full details. But a watermark is the perfect 'DRM', I'd say. No actual restrictions on what you can do, but if the authorities find pirate DVDs sold from a market stall at $2 apiece, or liberally distributed online, they are able to track down the originator through the watermark. Meanwhile, other people who aren't making copies to sell for profit or otherwise distribute (i.e. are only interested in exercising their fair-use rights) aren't impeded in any way, but can still make as many copies as they want, in whichever media they so choose.
To attempt an analogy, I'd have no problems with my copied media including a watermark identifying me as the source, in exactly the same way that I have no problem with having license plates traceable to me on my car. I'm not intending to do anything illegal with either, so I'm happy to attach my identity to it.
-Q
Sure it does -- on my Macs, I just open Sys Prefs, goto 'Network', and when I pick an interface (like, say, the topmost one with a green 'active' light), then I can see my IP address. And the important thing here (to me) is that I can see my IP even if I'm using DHCP. One thing which always annoys the crap out of me on XP is that the IP dialog (which takes a few clicks & modal dialogs to reach) has the option to either enter the IP or use DHCP, and if you use DHCP, the IP address field is not filled out (un-editably) with the obtained address. In this case, you have to go to the DOS prompt & use 'ipconfig'. Or at least, I've not found anything simpler for that.
-Q
In my understanding, this is essentially correct-- the technology to do this exists now. However, they can be sued for this discrimination. Under the new laws being written, there is no explicit prohibition on this activity, so activists in favour of Net Neutrality would like these prohibitions to be made explicit in the new laws. This is because there's a difference between seeking sanctions against someone who has obviously performed an action counter to the written laws, and seeking sanctions against a company who you stipulate has done some against the presumed spirit of the law. It's the difference between getting sanctions against Comcast via the federal rules under which Comcast operates its (limited) monopoly, and going after them using anti-trust law.
Essentially, there are ways and means for these common carriers to be stopped, legally, from doing this sort of thing. The new rules (new in that they apply to the Internet, I believe, wheras the current rules apply to all forms of communication) do not have that provision, thus essentially making the Internet an area where common carriers can behave in that manner. There is great opposition to this, because the CCs would have us believe that it'll stop them using any QoS at all, and that they wouldn't be able to provide tiered service, etc. However, when you consider that we simply want the competition rules from the existing legislation placed into this new Internet-specific legislation, one has to wonder how it will create restrictions: they are the same rules they're following now.
Another poster put it quite well: at the moment, they aren't allowed to prioritize traffic based on source. They can prioritize different *types* of traffic, but they aren't allowed to (for example) give their own video/VoIP traffic better throughput than their competitors. So, AT&T can give VoIP high priority, but they must do so for everyone; they are not allowed to give their own VoIP high priority while leaving Vonage customers with standard or low priority. This is how it works now, with the existing legislation. The new stuff doesn't explicitly say that, and, given the comments made by folks at Comcast & others, we feel it is unsafe to leave these rules un-codified, because we believe the little buggers will take advantage of that situation.
-Q
The thing most folks are concerned with is the ability for a network provider to request money from someone with whom they currently have no business relationship, and to penalize anyone who doesn't pay up. Here's an example:
Now, the government is currently trying to enact legislation which will make the above possible. The supporters of the Net Neutrality movement argue that the rules should stay as they are: we've not needed explicit rules before, we shouldn't be adding them now. The opponents of the movement argue that network companies shouldn't be stopped from using Quality-of-Service in their offerings. Now, there were some important points there:
Firstly, the existing legislation is effectively in favour of Net Neutrality; it doesn't grant any privileges which aren't intrinsic to the operation of the system as a whole. There is new legislation being created which changes that, however, and that new legislation is what people are trying to get rid of, to keep the existing level playing field.
Secondly, you see the argument that Net Neutrality shouldn't be allowed because then Bell won't be able to charge more for higher bandwidth, or for better quality of service, and so on. This is a red herring, however: Net Neutrality supporters don't much care about that. We don't expect that everything will cost the same. It's perfectly acceptable to us that any consumer -- be they private or corporate -- desiring higher access speeds or better quality of service would pay extra for that. It's a service, you pay for it. That's fine. What we don't like is the way that a company like AT&T or Comcast could potentially charge money from any company whose data crosses their network at any point.
So, if an AT&T customer uses Google, they would ask Google for money. The AT&T customer is already paying them, and is getting exactly what they paid for. Google is paying their provider, and getting what they paid for. Some network providers, however, believe that data crossing their network is not being paid for, and so should be able to request reimbursement from the content providers. At which point one might well ask: What are the consumers of AT&T's home DSL service paying for, if not for their traffic to be routed across AT&T's network?
The arguments come thick & fast, but it ultimately comes down to something similar to that employed by Universal against the iPod and (successfully) the Zune: These people make money by selling something which works alongside our product. Even though we're paid for our product, we want money from the device our product works with, because without our product, the device couldn't function.
So, I hope this clears things up for you: charging your customers extra for better QoS is not a problem. Charging people who aren't your customers for QoS -- or explicitly lowering QoS for companies who don't hand you money -- is not. We're not asking the government to create rules disallowing it, we'd just like the new rules enabling that behaviour to be removed please, or at least re
Strange -- all the Best Buys in Toronto had signs up saying exactly how many there were available. I'd have thought they all would have had that.
-Q