I had something similar happen to me at Zellers, having waited since 6am at Best Buy to be 115th in line for 110 consoles. In my case, there were twenty people in line, and we were told they only had nine consoles available, so a bunch of us went off to find somewhere else (although by now it was almost 9am).
Around noon I find out that this store actually had one hundred and six consoles available. Not nine. Of course, they'd sold out inside the first hour of being open-- they didn't even have enough people waiting in line to eat 'em all up, in fact.
Takes the fucking piss, doesn't it? Well, I guess someone somewhere is having a laugh. Wanker.
Oh, and I'm told that Zellers in Canada has one of the highest allocations of Wii units. They're apparently expecting one more shipment before Christmas, and hopefully that will come in before my wife's birthday on December 2nd. Although, having spent the best part of seven hours yesterday going to every store in my area I thought I'd have a chance with (about 25 or 30 in total, I think), then if someone tries to pull a stunt like that to me while I'm queueing for the next shipment -- well, let's just say it'll get more news coverage than launch day, capice?
Well, actually the "game industry" opinions DO matter. Consumers will have a hard time playing games on a system if most of the developers don't make games for that system.
Actually, speaking as someone with a few (tentative) connections with some very high-profile game developers, and therefore some small insight into the strange ways their minds work, I think the following axiom will explain things a little better:
When developers are excited about the Wii, they will be more interested in what they can do with that, and will therefore come up with more/better ideas of how to use it.
Therefore, we are likely to see a number of fairly exciting things happening on the Wii, purely because it sparks the imagination of those who are making the games for it. It's actually interesting and novel, so the problem-solving types who develop the games are going to have a field day playing around and seeing what they can do with the Wiimote & so on.
That's a large part of why I (as a developer who will hopefully be working at a huge game studio some time in the next 12 months, if my wife agrees to the move) am planning on buying one on Sunday, when I'm just not interested enough in the Xbox 360 or the PS3. The allure of the Wii is in its novelty, meaning it will be intriguing and exciting. The lure of the Xbox360 and PS3 are the prettier graphics and the fact that new games won't be released for the preceding generation any more.
-Q
Re:Hm... I was a liberal before I read this thread
on
Time For Anti-Trust 2.0?
·
· Score: 3, Interesting
Well, sadly I can't provide a citation for this (although hey, this is Slashdot-- citations are for wimps, right?), but I was under the impression that the deal worked something like this:
Do as MS asks (only sell Windows, avoid bundling things MS doesn't like)-- pay in the region of $25-$50 for each Windows license.
Do your own thing: pay full retail price.
In the post-Dell world of low-margin commodity PC's, the difference is likely to be at least $100, possibly more. Hell, there are even things like 'co-marketing' grants from the likes of MS and Intel, where the OEM gets money in return for putting MS or Intel prominently in their advertising, and I'm sure that the MS one offsets most of the remaining cost of the Windows licenses. However, when you're competing for a slice of the $500 PC market, you don't want your $25 copy of Windows to start costing $150 now. Or, in the case of Vista, $200 or more (because no-one wants the basic versions, as Acer suggests). Now, if you don't get favourable pricing, your offering either costs $700 compared to the competition's $500, or else you're going to lose money on every unit sold.
It's not the potential markup on a $1400 PC that hurts -- it's the markup on a $400 or $500 PC that hurts, because the retail price of Windows will increase that by a fairly noticeable percentage.
If D doesn't provide any service to A, why does A care what D does? Oh, that's right -- because A benefits when D carries traffic at normal speeds. Therefore, D is providing a service to A, and A is a customer of D.
Yeah, and people who drive behind me on the road benefit from my driving at normal speeds, so therefore I should be able to charge them for that 'service'?
Now, if D were to give A's traffic higher speeds, that would be a service. But treating them the same as everyone else is not a service, it's just normal. It's like asking for protection money: pay me and you'll be treated like everyone else. Unless of course the law explicitly allows ISP D to consider 'no traffic routining' as its basic service, meaning that anything above that is special treatment requiring compensation. However, that's not likely to be the case, especially with D's direct customers (C, i.e. us) paying explicitly for the ability to access content at normal speeds. You can define normal to be a fairly low speed, and that's fine: so long as everything gets the same treatment, that's fine; it's when a particular entity is singled out for these lower speeds (usually a competitor, or someone with cash to be shaken-down) that it becomes wrong, and why some of us would like the law to mention somewhere that this is considered 'a bad thing'. You know, so that those of us who get the shaft have some legal recourse other than 'pay D whatever they want'.
And as for the argument for less government oversight, that might well work counter to the desired level of impartiality anyway, unless of course we can go back in time. You see, at the moment, most people get their internet access through the major telecommuications companies, or the cable companies. This especially includes the sites providing the services. Now, since they're (hypothetically) allowed to, these networks can slow down traffic from all the smaller ISPs and hosting companies. The net result? People use the big ones, because the smaller ones are being slowed down by their competitors. It's just like the adoption of Microsoft Office: everyone uses it because everyone else uses it. If I don't use Office, I can't (reliably) read.doc files. Maybe I can use OpenOffice. Maybe the document I want to read has something in it that OO balks at. Who knows? But that's the reason why Office is so ubiquitous. The advocates of Network Neutrality simply don't want the same thing to happen with ISPs: everyone uses Comcast, Rogers, Bell, or Verizon because they slow down traffic entering/leaving their own networks.
Better yet, just option-click on the app you want in the dock. Bazaam -- other windows gone, only that application's shown.
Actually, that just does the same as option-selecting the app by clicking a window: it only hides the prior application. Switch from Finder to Safari like this and your Finder windows will hide, but the Terminal windows you have open won't, for example.
The point is not whether a Linux ditribution existed prior to Windows 95, but whether it existed prior to Microsoft's software being installed on some high percentage of the world's IBM-compatible computers. The latter has been the case pretty much from the word go. When my dad bought a PC, he bought DR-DOS 6 to go with it, but never got around to installing it because the hard drive actually had MS-DOS 5 installed on it at the factory (the hard drive factory, that is -- apparently not uncommon back in 1991-ish). Until relatively recently, it's been fairly rare to find an IBM-compatible computer that does NOT use a Microsoft operating system. Sure, a few people back in the day would run DR-DOS, a few less would run something akin to BSD, although I have an idea the first PC-compatible BSD was for the 386, so that's got to be at least six or seven years after MS started shipping PC operating systems.
Sure, Linux distributions were available before Windows 95, but the same argument made by TFA existed back in 1993 too -- Microsoft's software was entrenched, it was the de facto system on most IBM-compatible computers, and it's reasonable to assume that a high proportion of the people using those would stick to what they have/know, rather than switch to something entirely new. Therefore, despite the existence of Linux, most folks stayed with DOS & Windows 3 until Win95 came along, which was a funkier Windows which didn't need you to mess about with DOS to get it running.
It isn't exactly 'minimizing', but there's always 'Hide [AppName]' and 'Hide Others' on the Application menu. So you can switch to Firefox and choose 'Hide Others' to reduce your clutter to only incode Firefox windows.
There are also various little extra things you can do with, for instance, the Option key. Click on an application window whilst holding the Option key and the target application will be activated while the current will be hidden. Hold down the Option key and click the minimize button on a window (or while pressing Cmd-M) and all windows in the application will be minimized. While you're looking through the menus in may applications (chiefly it's the Apple ones that actually implement this, so try Finder & Safari), tap the Option key. You'll likely see some items change -- Minimize Window becomes Minimize All. Close Window becomes Close All Windows. The ellipses after things like shutdown, restart, logout, and empty trash all disappear (meaning it won't put up an 'Are you sure?' prompt).
On the whole, the Macintosh interface is designed to make the things you need readily accessible -- in the words of Penny Arcade's Tycho, it's goal is that of "exposing functionality" -- and it does this pretty well. However, you'll likely find yourself surprised at the amount of more advanced functionality that's tucked just out of sight, yet always close enough that it isn't difficult to reach. The Option key is very often involved here, enough so that I sometimes just try doing normal things while hold Option, just to see if something different will happen...
My real question here is, how much of Leopard 'really' is a 64bit OS? Are ANY of the drivers really 64bit, or is the kernel mode they are running in, still a 32bit environment?
The reason that this seems really suspect, is the Intel based MacBooks are running on a 32bit CPU, no 64bit whatsoever. So is there separate versions for the MacBooks, or is Leopard once again trying to pretend to be a 64bit OS, like Apple touted OSX as 3 years ago, when it wasn't?
It's probably worth pointing out at this juncture that Leopard hasn't been released yet. So, the fact that the MacBooks currently aren't 64-bit capable has little or no bearing on the issue.
It's also worth pointing out, since you appear to have forgotten this part of the grandparent's post while making this argument, that Leopard will support both 32-bit and 64-bit machines. It's not just 64-bit, and able to load 32-bit drivers-- it will ship using universal (i.e. 'fat') binaries where applicable, meaning that on 32-bit machines it would use 32-bit binaries, and on 64-bit it can use 64-bit binaries. Also, since both will be installed together, then you can run your 64-bit apps alongside your 32-bit apps, and each will load the appropriate implementation of the system libraries. Exactly the same as the non-GUI apps in OS X 10.4 can do now, on the G5 and on the Xeon-based Mac Pro announced this past week.
32-bit and 64-bit on the Mac aren't mutually exclusive, because they use these universal/fat binaries. You'll not go to the store and buy the 32-bit or 64-bit version of Mac OS, any more than you'd go and buy the PowerPC or Intel versions. They'll ship in the same box. The Installer application has had support since at least OS X 10.2 for installing only particular architectures from a fat binary within its archive. That probably comes from its NeXTStep heritage, which could happily handle fat-binary applications compiled for Motorola, Intel, and Sparc architectures. So, when you buy a copy of OS X, I'd guess it'll have all architectures on the DVDs, and at install time it (may) install only what's appropriate: 32-bit ppc on G4 and lower, 32-bit Intel on Core Duo, then 32- & 64-bit ppc on G5, and 32- and 64-bit i386 on Xeon or Core 2 Duo. But hey, that's just a guess.
Microsoft debated on whether to let the x64 version of Windows do a mixed mode 32bit driver support, and the team chose to abandon 32bit drivers for several reasons. One of them hoping to force hardware vendors to write 'better' drivers.
Of course, I can say this for sure until I get my hands on a preview copy of Leopard (I'm an ADC member, but not at WWDC, so I have to wait for either a download or a DVD in the mail to see it for myself), but given the wway they've handled it in user-space, I'm assuming that kernel-mode will work in much the same way: you can have Xcode build a 'universal' binary containing multiple architectures, so potentially that could include ppc, i386, ppc64, and x64. All from the same code (well, unless you've got assembler in there, but then quite frankly the onus is on you to handle the differences).
Now, it's been a couple of years since I delved much into Windows programming, so don't shout if I'm a little off-target, but here's a key difference between in code compatibility between Apple's and Microsoft's 64-bit efforts: Microsoft uses ILP64, Apple uses LP64. That means that on 64-bit Windows, ints, long ints, and pointers are all 64-bit quantities. On 64-bit Mac OS, ints are still 32-bit, while long ints and pointers are 64-bit. That means that for programmers on the Mac, if we've been relatively careful to use 'int' for our basic 32-bit types rather than 'long', then that code will compile happily for both 32- abd 64-bit environments. When we're casting pointers we need to be more careful, however. In contrast, Microsoft likely picked ILP64 to avoid the 32- vs. 64-bit rounding that could happen if your code routinely casts pointers to
Yep, that's true, mostly due to middle management mandating Active Directory, from what I've heard (I talk to a lot of Mac shops with Windows servers).
The sad thing about this is that Microsoft's AFP service hasn't seen a substantial update since Windows 2000. It still supports AFP 2.3, which (IIRC) dates from about Mac OS 8.6....? So, for folks using it, you miss out on support for Unix-style privileges, UTF-8 character encoding support, and support for filenames in excess of 31 characters in length. That last one means that if your OS X home folder is mounted from an MS AFP server, then you'll not be able to launch Classic, for example: it needs to create a preference file with 32 (or is it 33?) characters in its name, and the server won't let it.
Most of the folks I know using Windows for AFP services use third-party AFP server software.
Boss: I see you've requested a GeForce 12000 graphics card and a PhysX 4 'physics card'? What are these for?
Me: I have to routinely handle thousands of documents each day, and my computer gets really bogged down when manipulating them. These little cards will increase my productivity immensely.
Boss: Okay, that should be fine, then, here you go.
Me: Woohoo! Quake fest!
I think it's vitally important that this desktop metaphor be used in offices everywhere. I'll nominate my own office as a test site.
I had all those -- the remastered, cleaned-up copies of the original releases? The quote wasn't that this was the last chance to purchase the films, it was this was likely their last chance to clean up and remaster the original negatives. The reason being, the negatives were so badly degraded by this point that if they had waited a few years more, they wouldn't have been able to 'rescue' as much as they had-- we'd have been stuck a dodgy faded version for all time.
I believe that some information that will help explain this is to be found here. It's best to read that article for yourself, but I'll provide a little abstraction of some of the details myself, although this isn't really my area of expertise:
The main point revolves around the fact that MS' OpenXML uses a non-mixed content model, while OpenDocument uses a mixed content model. This means that OpenDocument can have tags interspersed with regular text, or tags within text delimited by other tags, etc. However, OpenXML cannot do this: all text must reside within a tag, and only text or tags can reside within other tags. The article gives a textual example of this. To the computer, the MS one is probably closer to the internal representation of the data: object-oriented programmers will probably recognise the structure as an object encoding its member variables. However, it pretty much removes the benefit of using XML in the first place: source readability. If you look at HTML, it's fairly easy to change a couple words around, and make a few italic, or bold. But in the OpenXML format, that becomes a more laborious task.
The article goes on to make arguments which back up the basic premise given here. You can also see from the examples how the tags differ in type. They give examples in OpenXML, ODF, and XHTML. Just looking at the tags in the OpenXML source doesn't give you any real idea what they're doing-- I mean, what does <w:rPr> mean? However, the tags used in ODF are longer and easier to read and understand for a human.
Of course, you could say that human-readability isn't an issue, and that's a fairly valid argument. However, if human-readability isn't an issue, why use XML? Why not do what Office was doing before, and writing memory out to disk, or basically serializing the document object tree in binary? It'll be smaller and easier for the computer. The whole point of using XML is to make the data easily understandable to humans, to the point where we can make numerous (albeit potentially quite small) changes without needing a program to interpret the data for us. Or where it's possible for us to write an app that understands the data, which pretty much requires that we personally understand it. As it stands, just about any XML data format is quite self-explanatory in itself, which is why we have XML.
Maybe that doesn't answer everyone's questions, but I hope it proves at least a decent starting point.
If you install software which corrupts your partition table, you can always wipe the disk & re-install.
If you raise the clock speed & heat output on your GPU and it cooks other components, or burns up due to not having enough heat dissipation to run at that speed, then you need to replace the hardware.
The first situation is easily sortable. The second situation depends on whether the manufacturer will replace the machine under warranty. If they won't (which is reasonable -- you would have to go through some awkward steps to do this) then you've got a nice new Apple-branded flower press.
Personally, I'd love to bump the clock rate, if I had one. But I'd wait to see if the only adverse effect is a more noisy fan. I'd also likely wait for an OS X utility that would switch it, because I'd want to raise the clock speed only when I'm about to *use* it, which would likely only be for certain things (i.e. the latest games which don't play well with a lowered clock).
Grrr, sometimes I hate the ADC discounts. Members in the US get the price dropped by US$460. Members in Canada get the price dropped by CDN$165. Also known as US$145. Guess which one I get?
I would personally argue that there has to be a parallel with libel cases here. The First Amendment says that the govenment will not legislate to restrict freedom of speech; in this case, it's being argued that juducial precedent here will also act to restrict general freedom of speech, contrary to the promises of the First Amendment. However, no-one argues when the case is about libel. In fact, it's a given that the courts' powers are needed to settle a libel case satisfactorily, so there is a precedent for a court ruling on a potential First Amendment issue where it hasn't affected the 'right to free speech'.
I would argue that a useful test for this case and others like it would be:
Is the violation of the trade secret actionable if the blogger/journalist, instead of printing and thus widely disseminating it, gave it directly to a competitor of the secret's owner?
In other words, if the blogger only told one person about the trade secret, and this person was in a position to make such use of the secret as to cause harm to the secret's owner, would the blogger still be entitled to First Amendment rights on free speech? Or could he be ordered by a court to provide the name of his source? Or does the fact that he told everyone via a [website|magazine|broadsheet] gain him extra privileges?
You see, First Amendment aside, it raises a very interesting and important question: the person who contacted PowerPage was under NDA, and violated that. If the court rules against Apple, then it means that non-disclosure agreements can be considered null and void provided you disclose for the purpose of widespread dissemination. It says "okay, you agree not to tell anyone about what you're doing. Well, except someone who'll tell everyone else. That's okay, because it's covered by First Amendment press rights, which means we're not allowed to find out who did it. But if you tell our competitors directly, you're toast." If the information is of a type covered by whistleblower laws (i.e. if it discloses a crime, or if withholding such information is likely to cause harm), then the 'leaker' is protected by those. If the whistleblower laws aren't appropriate, then they aren't protected, and they therefore shouldn't be allowed to hide behind journalists, bloggers, or anyone. If they're not allowed to tell Bill Gates about the stunning nw things being planned for OS X 10.6, they shouldn't be given express permission to tell Walt Mossberg or Paul Thurrott either. But a ruling against Apple in this case kinda leans that way, to my eye.
As to the comment about C|Net & the Intel switch, I would argue that that had less effect than this. It was 'leaked' a couple of days before the official announcement. Certainly not so far back that Apple's competitors could use the knowledge to significantly harm Apple. However, seeing that the 'Asteroid' project still hasn't appeared, I would conjecture that it was not close to release, and that in fact when the information was published on PowerPage a competitor found out about it and basically scuppered the project for Apple:
Imagine that Apple had an agreement with another company that this other company would provide similar hardware for the Mac, not just for PCs; now imagine that this company is renewing a five-yearly contract by which it agrees to make products with support for the Macintosh; now imagine that, upon reading PowerPage, they turn to Apple and say they'll drop the Mac market completely unless Apple drops the project-- hands it over as part of their part of the project, in fact.
Of course, we don't know anything about it for certain, but certainly that scenario isn't entirely far-fetched. And it's quite possible that Apple is very keen to know just who wasted the couple million dollars they pumped into R & D on this thing. I know I would be.
The thing to remember about USB et al (and what the grandparent was trying to say) is not that Apple created it, or was the first to implement or so on, but that they were the major driving force behind its adoption.
I can't really see the connection with gigabit ethernet and 802.11g -- Apple was among the first (possibly the first, I'm not really sure) to implement these features as standard, but these technologies weren't being given short shrift by others in any way. In that case, perhaps Apple can claim to be the first (or near-first) company to standardise on these new technologies across their entire range, but that's not really a big deal when everyone else was already doing the same.
USB however, I remember. I remember it because it was in 1998/1999 when I was starting out in computer programming. Printers were still almost all using parallel ports. The PalmPilot was using 9-pin serial. Mice were using either 9-pin serial or PS/2. A lot of keyboards were still using the old 'keyboard port' (was this called PS/1? I never heard it described as anything other than the 'keyboard port'). I honestly don't remember what external CD drives were using, although I can remember that my first Zip drive used a parallel port, and I'm pretty darned sure I bought that in 1999.
When the iMac came out, it standardized on USB. Everything was using USB. No ADB ports, no serial, no parallel, no SCSI. Not even FireWire. Just the USB ports. They had a hub in the keyboard, and they were making monitors that contained hubs too (although those might have arrived later in 1999, I'm not sure). It was USB or nothing.
At the time, lots of folks were predicting that this would fail because -- and this bit is important, so pay attention please -- hardly any peripherals used USB. They were all parallel, serial, or SCSI. Or in the case of mice & keyboards, they used PS/2 or ADB. And yet look what happened: Lots of fruit-colored peripherals appeared, all using USB. The iMac was cute enough to garner attention, and the device manufacturers wanted part of that market. So they started making USB stuff en masse. By the end of 2000 it was getting hard to buy a printer that had a parallel port, and they all had USB ports. FOlks point out that USB was a wintel thing, and Windows had it since 1996 or 1997. But it wasn't until Apple made it the only option that everything started using it. Not much point doing otherwise, given that their current ports were still supported otherwise -- why make the effort?
As to firewire -- well, I always saw that as analogous to SCSI, as it was designed for bulk transfer of data to and from large storage devices. USB was a peripheral interconnect, for mice, cameras, keyboards, printers, and so on. Geared mostly towards burst transmission in relatively small bursts. They had different uses. But again, as far as I can recall (and I may be wrong) Apple was using USB along with and possibly even before it did FireWire. Certainly the iMacs had USB before they had FireWire.
While I agree that this is unlikely, I can see a potential positive outcome for Apple in doing this, and it's tied to the findings of the MS antitrust case.
Remember there, where it was found that Microsoft's main thrust was to have developers adopt the Windows APIs? The reason they took a hard stance against Netscape and Java was because they exposed APIs which didn't tie developers (and therefore, consumers) to the Windows platform. Microsoft saw the creation of large-scale APIs upon which applications could be built for more platforms than just their own as a major threat. The idea is to keep the "applications barrier to entry" high, so that it's not so easy for people to move away from Windows.
As unlikely as it may ultimately prove, the case for Yellow Box is fairly clear: give developers a good cross-platform API that will allow them to write applications to run on both Windows and the Macintosh, and you add value to the Macintosh platform. And since the Cocoa APIs are considered good by a great number of developers, there are already folks who will happily use it, and may potentially convince their friends.
At the end of the day, perhaps developers might choose not to write Mac versions of their Windows apps due to constraints of time or money. But if they could write it once and sell to both markets, then that's a clear & immediate benefit-- assuming they're happy to use the Cocoa/Carbon APIs, anyway.
Disclaimer: I write network management software for Mac OS X; I have therefore seen a fair bit of what can happen with mis-configured system folders
I'd advise you not to change permissions on/Library, or at least please don't do it recursively. You're asking for pain there./Library/Application Services,/Library/Caches,/Library/Frameworks are supposed to be writable by administrators.
The reason your root library folder is writable by members of the Admin group is because that's what it's for. There's/System/Library, which is owned by root/wheel. There's/Library, which is where the machine's administrator can install things for all other users, and there's ~/Library where any user can write their own things into their own personal space.
The reason the root one is writable by admins is simply because that's the place where admins (which are, you know, admins for a reason) can write things. Things like all the fonts installed by Macromedia Flash. Things like all the project templates, SCM, Design, WebObjectsGUI plugins for Xcode. Things like InterfaceBuilder palettes. Things like Adobe fonts, SVG viewer resources, color profiles. You know, thing used by all users of the machine. But which a machine administrator can change or remove. That's kinda the point of the Admin group.
Also, please take note that the sticky bit is set on the Library folder. So you'll need to chmod 1775/Library. Oh, and I hope you're prepared for some stuff to stop working, because it quite likely will. I've seen whata happens when people decide to arbitrarily make most of the system writable only by their One True User (whoever that may be). I then get many tech support calls where we try to figure out why my software is making all their software stop working. It then transpires that their software just doesn't have permission to access the disk, and just can't install things, use caches, etc. Or it's using a home folder -- mounted from a remote server -- for all that, and is therefore taking *ages* since another fifty people are doing the same thing.
At the end of the day, there probably is an argument for not letting Admin account create folders within the/Library folder, so for example only root can create the InputManagers folder. That would be the same as the StartupItems thing, and it's likely what Apple will do. But don't apply those rules to Application Support and suchlike. It'll hurt, believe me.
There are routines to get the path to a bundle's executable file. It doesn't matter what the extension is, etc. So the Finder can very easily determine whether something is in fact executable. For an example, pop open the Inspector window in the Finder (Cmd-Opt-i) and select a few file. If they're applications, that window will tell you so. If it doesn't say they're an app, the Finder won't even try to launch them. Also, in 10.4.4 upwards, it'll put 'Universal', 'Intel', or 'PowerPC' after the file kind. So, it's not at all difficult to have the Finder flag executable files with a badge.
...he basically says single player gaming is like masturbation, which I suppose could mean that it's practiced and loved by EVERYONE... but that's not what he meant.
Don't knock masturbation: it's sex with someone you love.
That's weird, I could have sworn the dynamic pager at least had 64-bit memory access, but I guess it doesn't need >4Gb itself, and neither does the kernel. I've confirmed that there aren't any __ppc64__ macros in the source either.
As for this:
pointers don't fit into an int; the language hasn't guaranteed that they do for a long time now, but that doesn't completely prevent people from writing code, either intentionally or accidentally, that requires that they do.
Well, at least that shifts the onus onto people who *want* >4Gb memory access. And those who aren't bothered about it can go on as they are now, potentially assuming that pointers will fit into an int. I still feel that this is a better way of working it than to redefine the types completely for all application on a host OS. I mean, if I were writing something like Office, I really wouldn't like the idea that I had to rewrite the application completely due to the OS going entirely 64-bit, and the basic types are changing. However, if I chose to go 64-bit, then that's not a problem.
Also, the further thought occurs, as an argument to those who would insist contrary to the above sentiment: People complain now that a Dashboard widget can take up 200Mb of virtual memory (note that: virtual memory). Since these things are supposed to use such little memory, why should it be desirable that they have access to a 64-bit address range? Since that's just about all they would get from the 64-bit support, why bother?
Make the 64-bit address space available to those that need/want it, but not required for those that don't. Seems like a fairly simple idea to me.
Slashdot Mirror
I had something similar happen to me at Zellers, having waited since 6am at Best Buy to be 115th in line for 110 consoles. In my case, there were twenty people in line, and we were told they only had nine consoles available, so a bunch of us went off to find somewhere else (although by now it was almost 9am).
Around noon I find out that this store actually had one hundred and six consoles available. Not nine. Of course, they'd sold out inside the first hour of being open-- they didn't even have enough people waiting in line to eat 'em all up, in fact.
Takes the fucking piss, doesn't it? Well, I guess someone somewhere is having a laugh. Wanker.
Oh, and I'm told that Zellers in Canada has one of the highest allocations of Wii units. They're apparently expecting one more shipment before Christmas, and hopefully that will come in before my wife's birthday on December 2nd. Although, having spent the best part of seven hours yesterday going to every store in my area I thought I'd have a chance with (about 25 or 30 in total, I think), then if someone tries to pull a stunt like that to me while I'm queueing for the next shipment -- well, let's just say it'll get more news coverage than launch day, capice?
-Q
Actually, speaking as someone with a few (tentative) connections with some very high-profile game developers, and therefore some small insight into the strange ways their minds work, I think the following axiom will explain things a little better:
When developers are excited about the Wii, they will be more interested in what they can do with that, and will therefore come up with more/better ideas of how to use it.
Therefore, we are likely to see a number of fairly exciting things happening on the Wii, purely because it sparks the imagination of those who are making the games for it. It's actually interesting and novel, so the problem-solving types who develop the games are going to have a field day playing around and seeing what they can do with the Wiimote & so on.
That's a large part of why I (as a developer who will hopefully be working at a huge game studio some time in the next 12 months, if my wife agrees to the move) am planning on buying one on Sunday, when I'm just not interested enough in the Xbox 360 or the PS3. The allure of the Wii is in its novelty, meaning it will be intriguing and exciting. The lure of the Xbox360 and PS3 are the prettier graphics and the fact that new games won't be released for the preceding generation any more.
-Q
Well, sadly I can't provide a citation for this (although hey, this is Slashdot-- citations are for wimps, right?), but I was under the impression that the deal worked something like this:
In the post-Dell world of low-margin commodity PC's, the difference is likely to be at least $100, possibly more. Hell, there are even things like 'co-marketing' grants from the likes of MS and Intel, where the OEM gets money in return for putting MS or Intel prominently in their advertising, and I'm sure that the MS one offsets most of the remaining cost of the Windows licenses. However, when you're competing for a slice of the $500 PC market, you don't want your $25 copy of Windows to start costing $150 now. Or, in the case of Vista, $200 or more (because no-one wants the basic versions, as Acer suggests). Now, if you don't get favourable pricing, your offering either costs $700 compared to the competition's $500, or else you're going to lose money on every unit sold.
It's not the potential markup on a $1400 PC that hurts -- it's the markup on a $400 or $500 PC that hurts, because the retail price of Windows will increase that by a fairly noticeable percentage.
-Q
Yeah, and people who drive behind me on the road benefit from my driving at normal speeds, so therefore I should be able to charge them for that 'service'?
Now, if D were to give A's traffic higher speeds, that would be a service. But treating them the same as everyone else is not a service, it's just normal. It's like asking for protection money: pay me and you'll be treated like everyone else. Unless of course the law explicitly allows ISP D to consider 'no traffic routining' as its basic service, meaning that anything above that is special treatment requiring compensation. However, that's not likely to be the case, especially with D's direct customers (C, i.e. us) paying explicitly for the ability to access content at normal speeds. You can define normal to be a fairly low speed, and that's fine: so long as everything gets the same treatment, that's fine; it's when a particular entity is singled out for these lower speeds (usually a competitor, or someone with cash to be shaken-down) that it becomes wrong, and why some of us would like the law to mention somewhere that this is considered 'a bad thing'. You know, so that those of us who get the shaft have some legal recourse other than 'pay D whatever they want'.
And as for the argument for less government oversight, that might well work counter to the desired level of impartiality anyway, unless of course we can go back in time. You see, at the moment, most people get their internet access through the major telecommuications companies, or the cable companies. This especially includes the sites providing the services. Now, since they're (hypothetically) allowed to, these networks can slow down traffic from all the smaller ISPs and hosting companies. The net result? People use the big ones, because the smaller ones are being slowed down by their competitors. It's just like the adoption of Microsoft Office: everyone uses it because everyone else uses it. If I don't use Office, I can't (reliably) read .doc files. Maybe I can use OpenOffice. Maybe the document I want to read has something in it that OO balks at. Who knows? But that's the reason why Office is so ubiquitous. The advocates of Network Neutrality simply don't want the same thing to happen with ISPs: everyone uses Comcast, Rogers, Bell, or Verizon because they slow down traffic entering/leaving their own networks.
-Q
Dammit, I get mod points all the time, and when someone finally posts what the Network Neutrality debate is really all about, I don't have any.
-Q
Aaaahhhhhhhh... Knew I'd seen that somewhere, couldn't think what it was. I thought I'd tried Cmd-Opt-Click too. Doh.
Thanks for pointing that out for me :o)
-Q
Actually, that just does the same as option-selecting the app by clicking a window: it only hides the prior application. Switch from Finder to Safari like this and your Finder windows will hide, but the Terminal windows you have open won't, for example.
-Q
The point is not whether a Linux ditribution existed prior to Windows 95, but whether it existed prior to Microsoft's software being installed on some high percentage of the world's IBM-compatible computers. The latter has been the case pretty much from the word go. When my dad bought a PC, he bought DR-DOS 6 to go with it, but never got around to installing it because the hard drive actually had MS-DOS 5 installed on it at the factory (the hard drive factory, that is -- apparently not uncommon back in 1991-ish). Until relatively recently, it's been fairly rare to find an IBM-compatible computer that does NOT use a Microsoft operating system. Sure, a few people back in the day would run DR-DOS, a few less would run something akin to BSD, although I have an idea the first PC-compatible BSD was for the 386, so that's got to be at least six or seven years after MS started shipping PC operating systems.
Sure, Linux distributions were available before Windows 95, but the same argument made by TFA existed back in 1993 too -- Microsoft's software was entrenched, it was the de facto system on most IBM-compatible computers, and it's reasonable to assume that a high proportion of the people using those would stick to what they have/know, rather than switch to something entirely new. Therefore, despite the existence of Linux, most folks stayed with DOS & Windows 3 until Win95 came along, which was a funkier Windows which didn't need you to mess about with DOS to get it running.
-Q
It isn't exactly 'minimizing', but there's always 'Hide [AppName]' and 'Hide Others' on the Application menu. So you can switch to Firefox and choose 'Hide Others' to reduce your clutter to only incode Firefox windows.
There are also various little extra things you can do with, for instance, the Option key. Click on an application window whilst holding the Option key and the target application will be activated while the current will be hidden. Hold down the Option key and click the minimize button on a window (or while pressing Cmd-M) and all windows in the application will be minimized. While you're looking through the menus in may applications (chiefly it's the Apple ones that actually implement this, so try Finder & Safari), tap the Option key. You'll likely see some items change -- Minimize Window becomes Minimize All. Close Window becomes Close All Windows. The ellipses after things like shutdown, restart, logout, and empty trash all disappear (meaning it won't put up an 'Are you sure?' prompt).
On the whole, the Macintosh interface is designed to make the things you need readily accessible -- in the words of Penny Arcade's Tycho, it's goal is that of "exposing functionality" -- and it does this pretty well. However, you'll likely find yourself surprised at the amount of more advanced functionality that's tucked just out of sight, yet always close enough that it isn't difficult to reach. The Option key is very often involved here, enough so that I sometimes just try doing normal things while hold Option, just to see if something different will happen...
Hope this helps,
-Q
It's probably worth pointing out at this juncture that Leopard hasn't been released yet. So, the fact that the MacBooks currently aren't 64-bit capable has little or no bearing on the issue.
It's also worth pointing out, since you appear to have forgotten this part of the grandparent's post while making this argument, that Leopard will support both 32-bit and 64-bit machines. It's not just 64-bit, and able to load 32-bit drivers-- it will ship using universal (i.e. 'fat') binaries where applicable, meaning that on 32-bit machines it would use 32-bit binaries, and on 64-bit it can use 64-bit binaries. Also, since both will be installed together, then you can run your 64-bit apps alongside your 32-bit apps, and each will load the appropriate implementation of the system libraries. Exactly the same as the non-GUI apps in OS X 10.4 can do now, on the G5 and on the Xeon-based Mac Pro announced this past week.
32-bit and 64-bit on the Mac aren't mutually exclusive, because they use these universal/fat binaries. You'll not go to the store and buy the 32-bit or 64-bit version of Mac OS, any more than you'd go and buy the PowerPC or Intel versions. They'll ship in the same box. The Installer application has had support since at least OS X 10.2 for installing only particular architectures from a fat binary within its archive. That probably comes from its NeXTStep heritage, which could happily handle fat-binary applications compiled for Motorola, Intel, and Sparc architectures. So, when you buy a copy of OS X, I'd guess it'll have all architectures on the DVDs, and at install time it (may) install only what's appropriate: 32-bit ppc on G4 and lower, 32-bit Intel on Core Duo, then 32- & 64-bit ppc on G5, and 32- and 64-bit i386 on Xeon or Core 2 Duo. But hey, that's just a guess.
Of course, I can say this for sure until I get my hands on a preview copy of Leopard (I'm an ADC member, but not at WWDC, so I have to wait for either a download or a DVD in the mail to see it for myself), but given the wway they've handled it in user-space, I'm assuming that kernel-mode will work in much the same way: you can have Xcode build a 'universal' binary containing multiple architectures, so potentially that could include ppc, i386, ppc64, and x64. All from the same code (well, unless you've got assembler in there, but then quite frankly the onus is on you to handle the differences).
Now, it's been a couple of years since I delved much into Windows programming, so don't shout if I'm a little off-target, but here's a key difference between in code compatibility between Apple's and Microsoft's 64-bit efforts: Microsoft uses ILP64, Apple uses LP64. That means that on 64-bit Windows, ints, long ints, and pointers are all 64-bit quantities. On 64-bit Mac OS, ints are still 32-bit, while long ints and pointers are 64-bit. That means that for programmers on the Mac, if we've been relatively careful to use 'int' for our basic 32-bit types rather than 'long', then that code will compile happily for both 32- abd 64-bit environments. When we're casting pointers we need to be more careful, however. In contrast, Microsoft likely picked ILP64 to avoid the 32- vs. 64-bit rounding that could happen if your code routinely casts pointers to
My English teacher at high school always used to put it to us with this little witticism:
-Q
Yep, that's true, mostly due to middle management mandating Active Directory, from what I've heard (I talk to a lot of Mac shops with Windows servers).
The sad thing about this is that Microsoft's AFP service hasn't seen a substantial update since Windows 2000. It still supports AFP 2.3, which (IIRC) dates from about Mac OS 8.6....? So, for folks using it, you miss out on support for Unix-style privileges, UTF-8 character encoding support, and support for filenames in excess of 31 characters in length. That last one means that if your OS X home folder is mounted from an MS AFP server, then you'll not be able to launch Classic, for example: it needs to create a preference file with 32 (or is it 33?) characters in its name, and the server won't let it.
Most of the folks I know using Windows for AFP services use third-party AFP server software.
-Q
Hell yeah:
I think it's vitally important that this desktop metaphor be used in offices everywhere. I'll nominate my own office as a test site.
-Q
Hmmm.....
I think those terms imply a different meaning to me than what you intended...?
*childish giggle*
This karma-burning Viz (NSFW?) moment brought to you by the letter:
-Q
I had all those -- the remastered, cleaned-up copies of the original releases? The quote wasn't that this was the last chance to purchase the films, it was this was likely their last chance to clean up and remaster the original negatives. The reason being, the negatives were so badly degraded by this point that if they had waited a few years more, they wouldn't have been able to 'rescue' as much as they had-- we'd have been stuck a dodgy faded version for all time.
-Q
I believe that some information that will help explain this is to be found here. It's best to read that article for yourself, but I'll provide a little abstraction of some of the details myself, although this isn't really my area of expertise:
The main point revolves around the fact that MS' OpenXML uses a non-mixed content model, while OpenDocument uses a mixed content model. This means that OpenDocument can have tags interspersed with regular text, or tags within text delimited by other tags, etc. However, OpenXML cannot do this: all text must reside within a tag, and only text or tags can reside within other tags. The article gives a textual example of this. To the computer, the MS one is probably closer to the internal representation of the data: object-oriented programmers will probably recognise the structure as an object encoding its member variables. However, it pretty much removes the benefit of using XML in the first place: source readability. If you look at HTML, it's fairly easy to change a couple words around, and make a few italic, or bold. But in the OpenXML format, that becomes a more laborious task.
The article goes on to make arguments which back up the basic premise given here. You can also see from the examples how the tags differ in type. They give examples in OpenXML, ODF, and XHTML. Just looking at the tags in the OpenXML source doesn't give you any real idea what they're doing-- I mean, what does <w:rPr> mean? However, the tags used in ODF are longer and easier to read and understand for a human.
Of course, you could say that human-readability isn't an issue, and that's a fairly valid argument. However, if human-readability isn't an issue, why use XML? Why not do what Office was doing before, and writing memory out to disk, or basically serializing the document object tree in binary? It'll be smaller and easier for the computer. The whole point of using XML is to make the data easily understandable to humans, to the point where we can make numerous (albeit potentially quite small) changes without needing a program to interpret the data for us. Or where it's possible for us to write an app that understands the data, which pretty much requires that we personally understand it. As it stands, just about any XML data format is quite self-explanatory in itself, which is why we have XML.
Maybe that doesn't answer everyone's questions, but I hope it proves at least a decent starting point.
-Q
There's a difference though:
The first situation is easily sortable. The second situation depends on whether the manufacturer will replace the machine under warranty. If they won't (which is reasonable -- you would have to go through some awkward steps to do this) then you've got a nice new Apple-branded flower press.
Personally, I'd love to bump the clock rate, if I had one. But I'd wait to see if the only adverse effect is a more noisy fan. I'd also likely wait for an OS X utility that would switch it, because I'd want to raise the clock speed only when I'm about to *use* it, which would likely only be for certain things (i.e. the latest games which don't play well with a lowered clock).
-Q
Grrr, sometimes I hate the ADC discounts. Members in the US get the price dropped by US$460. Members in Canada get the price dropped by CDN$165. Also known as US$145. Guess which one I get?
-Q
I would personally argue that there has to be a parallel with libel cases here. The First Amendment says that the govenment will not legislate to restrict freedom of speech; in this case, it's being argued that juducial precedent here will also act to restrict general freedom of speech, contrary to the promises of the First Amendment. However, no-one argues when the case is about libel. In fact, it's a given that the courts' powers are needed to settle a libel case satisfactorily, so there is a precedent for a court ruling on a potential First Amendment issue where it hasn't affected the 'right to free speech'.
I would argue that a useful test for this case and others like it would be:
In other words, if the blogger only told one person about the trade secret, and this person was in a position to make such use of the secret as to cause harm to the secret's owner, would the blogger still be entitled to First Amendment rights on free speech? Or could he be ordered by a court to provide the name of his source? Or does the fact that he told everyone via a [website|magazine|broadsheet] gain him extra privileges?You see, First Amendment aside, it raises a very interesting and important question: the person who contacted PowerPage was under NDA, and violated that. If the court rules against Apple, then it means that non-disclosure agreements can be considered null and void provided you disclose for the purpose of widespread dissemination. It says "okay, you agree not to tell anyone about what you're doing. Well, except someone who'll tell everyone else. That's okay, because it's covered by First Amendment press rights, which means we're not allowed to find out who did it. But if you tell our competitors directly, you're toast." If the information is of a type covered by whistleblower laws (i.e. if it discloses a crime, or if withholding such information is likely to cause harm), then the 'leaker' is protected by those. If the whistleblower laws aren't appropriate, then they aren't protected, and they therefore shouldn't be allowed to hide behind journalists, bloggers, or anyone. If they're not allowed to tell Bill Gates about the stunning nw things being planned for OS X 10.6, they shouldn't be given express permission to tell Walt Mossberg or Paul Thurrott either. But a ruling against Apple in this case kinda leans that way, to my eye.
As to the comment about C|Net & the Intel switch, I would argue that that had less effect than this. It was 'leaked' a couple of days before the official announcement. Certainly not so far back that Apple's competitors could use the knowledge to significantly harm Apple. However, seeing that the 'Asteroid' project still hasn't appeared, I would conjecture that it was not close to release, and that in fact when the information was published on PowerPage a competitor found out about it and basically scuppered the project for Apple:
Imagine that Apple had an agreement with another company that this other company would provide similar hardware for the Mac, not just for PCs; now imagine that this company is renewing a five-yearly contract by which it agrees to make products with support for the Macintosh; now imagine that, upon reading PowerPage, they turn to Apple and say they'll drop the Mac market completely unless Apple drops the project-- hands it over as part of their part of the project, in fact.
Of course, we don't know anything about it for certain, but certainly that scenario isn't entirely far-fetched. And it's quite possible that Apple is very keen to know just who wasted the couple million dollars they pumped into R & D on this thing. I know I would be.
-Q
The thing to remember about USB et al (and what the grandparent was trying to say) is not that Apple created it, or was the first to implement or so on, but that they were the major driving force behind its adoption.
I can't really see the connection with gigabit ethernet and 802.11g -- Apple was among the first (possibly the first, I'm not really sure) to implement these features as standard, but these technologies weren't being given short shrift by others in any way. In that case, perhaps Apple can claim to be the first (or near-first) company to standardise on these new technologies across their entire range, but that's not really a big deal when everyone else was already doing the same.
USB however, I remember. I remember it because it was in 1998/1999 when I was starting out in computer programming. Printers were still almost all using parallel ports. The PalmPilot was using 9-pin serial. Mice were using either 9-pin serial or PS/2. A lot of keyboards were still using the old 'keyboard port' (was this called PS/1? I never heard it described as anything other than the 'keyboard port'). I honestly don't remember what external CD drives were using, although I can remember that my first Zip drive used a parallel port, and I'm pretty darned sure I bought that in 1999.
When the iMac came out, it standardized on USB. Everything was using USB. No ADB ports, no serial, no parallel, no SCSI. Not even FireWire. Just the USB ports. They had a hub in the keyboard, and they were making monitors that contained hubs too (although those might have arrived later in 1999, I'm not sure). It was USB or nothing.
At the time, lots of folks were predicting that this would fail because -- and this bit is important, so pay attention please -- hardly any peripherals used USB. They were all parallel, serial, or SCSI. Or in the case of mice & keyboards, they used PS/2 or ADB. And yet look what happened: Lots of fruit-colored peripherals appeared, all using USB. The iMac was cute enough to garner attention, and the device manufacturers wanted part of that market. So they started making USB stuff en masse. By the end of 2000 it was getting hard to buy a printer that had a parallel port, and they all had USB ports. FOlks point out that USB was a wintel thing, and Windows had it since 1996 or 1997. But it wasn't until Apple made it the only option that everything started using it. Not much point doing otherwise, given that their current ports were still supported otherwise -- why make the effort?
As to firewire -- well, I always saw that as analogous to SCSI, as it was designed for bulk transfer of data to and from large storage devices. USB was a peripheral interconnect, for mice, cameras, keyboards, printers, and so on. Geared mostly towards burst transmission in relatively small bursts. They had different uses. But again, as far as I can recall (and I may be wrong) Apple was using USB along with and possibly even before it did FireWire. Certainly the iMacs had USB before they had FireWire.
-Q
(-1, Offtopic; damn, there goes my karma)
While I agree that this is unlikely, I can see a potential positive outcome for Apple in doing this, and it's tied to the findings of the MS antitrust case.
Remember there, where it was found that Microsoft's main thrust was to have developers adopt the Windows APIs? The reason they took a hard stance against Netscape and Java was because they exposed APIs which didn't tie developers (and therefore, consumers) to the Windows platform. Microsoft saw the creation of large-scale APIs upon which applications could be built for more platforms than just their own as a major threat. The idea is to keep the "applications barrier to entry" high, so that it's not so easy for people to move away from Windows.
As unlikely as it may ultimately prove, the case for Yellow Box is fairly clear: give developers a good cross-platform API that will allow them to write applications to run on both Windows and the Macintosh, and you add value to the Macintosh platform. And since the Cocoa APIs are considered good by a great number of developers, there are already folks who will happily use it, and may potentially convince their friends.
At the end of the day, perhaps developers might choose not to write Mac versions of their Windows apps due to constraints of time or money. But if they could write it once and sell to both markets, then that's a clear & immediate benefit-- assuming they're happy to use the Cocoa/Carbon APIs, anyway.
-Q
Disclaimer: I write network management software for Mac OS X; I have therefore seen a fair bit of what can happen with mis-configured system folders
I'd advise you not to change permissions on /Library, or at least please don't do it recursively. You're asking for pain there. /Library/Application Services, /Library/Caches, /Library/Frameworks are supposed to be writable by administrators.
The reason your root library folder is writable by members of the Admin group is because that's what it's for. There's /System/Library, which is owned by root/wheel. There's /Library, which is where the machine's administrator can install things for all other users, and there's ~/Library where any user can write their own things into their own personal space.
The reason the root one is writable by admins is simply because that's the place where admins (which are, you know, admins for a reason) can write things. Things like all the fonts installed by Macromedia Flash. Things like all the project templates, SCM, Design, WebObjectsGUI plugins for Xcode. Things like InterfaceBuilder palettes. Things like Adobe fonts, SVG viewer resources, color profiles. You know, thing used by all users of the machine. But which a machine administrator can change or remove. That's kinda the point of the Admin group.
Also, please take note that the sticky bit is set on the Library folder. So you'll need to chmod 1775 /Library. Oh, and I hope you're prepared for some stuff to stop working, because it quite likely will. I've seen whata happens when people decide to arbitrarily make most of the system writable only by their One True User (whoever that may be). I then get many tech support calls where we try to figure out why my software is making all their software stop working. It then transpires that their software just doesn't have permission to access the disk, and just can't install things, use caches, etc. Or it's using a home folder -- mounted from a remote server -- for all that, and is therefore taking *ages* since another fifty people are doing the same thing.
At the end of the day, there probably is an argument for not letting Admin account create folders within the /Library folder, so for example only root can create the InputManagers folder. That would be the same as the StartupItems thing, and it's likely what Apple will do. But don't apply those rules to Application Support and suchlike. It'll hurt, believe me.
-Q
There are routines to get the path to a bundle's executable file. It doesn't matter what the extension is, etc. So the Finder can very easily determine whether something is in fact executable. For an example, pop open the Inspector window in the Finder (Cmd-Opt-i) and select a few file. If they're applications, that window will tell you so. If it doesn't say they're an app, the Finder won't even try to launch them. Also, in 10.4.4 upwards, it'll put 'Universal', 'Intel', or 'PowerPC' after the file kind. So, it's not at all difficult to have the Finder flag executable files with a badge.
-Q
Don't knock masturbation: it's sex with someone you love.
[/WoodyAllen]
-Q
That's weird, I could have sworn the dynamic pager at least had 64-bit memory access, but I guess it doesn't need >4Gb itself, and neither does the kernel. I've confirmed that there aren't any __ppc64__ macros in the source either.
As for this:
Well, at least that shifts the onus onto people who *want* >4Gb memory access. And those who aren't bothered about it can go on as they are now, potentially assuming that pointers will fit into an int. I still feel that this is a better way of working it than to redefine the types completely for all application on a host OS. I mean, if I were writing something like Office, I really wouldn't like the idea that I had to rewrite the application completely due to the OS going entirely 64-bit, and the basic types are changing. However, if I chose to go 64-bit, then that's not a problem.Also, the further thought occurs, as an argument to those who would insist contrary to the above sentiment: People complain now that a Dashboard widget can take up 200Mb of virtual memory (note that: virtual memory). Since these things are supposed to use such little memory, why should it be desirable that they have access to a 64-bit address range? Since that's just about all they would get from the 64-bit support, why bother?
Make the 64-bit address space available to those that need/want it, but not required for those that don't. Seems like a fairly simple idea to me.
-Q