In my world though, moving our servers to the 64bit version of Windows took our server requirments to less than 1/5 the equivalent systems when running the 32bit version of Windows 2003 Server.
And this was because:
1. You redesigned all your services to use 64-bit large-address space code where you had previously been using read/write to access a large disk-based object through a 2G "windows".
2. Newer computers are generally faster than old ones, and Opteron's instruction set is faster than IA32 because of the slightly cleaner ABI and the larger register file.
3. You're running Oracle, and Oracle through utterly heroic measures has managed to take advantage of the "32-bit-segmented" mode of the Xeon to get option 1 working, so your speedup is a special case that most people can't take advantage of.
the Application would have to broken up to have a 32bit interface and only use the 64bit code for intensive calculations.
And this is a problem... why? I mean, this is a completely normal way to build GUI applications. Every UNIX GUI application, except for a few videogames that use an SDL interface to the raw frame buffer on Linux, is client-server, and most high-performance ones use OpenGL as well so you have part of the application running in the client, part on the display server, and part in the GPU, and all three of these parts can be in different processors using different instruction sets. I mean right now I'm running UNIX GUI applications on a 64-bit Alpha, a Xeon running Linux, a 32-bit G4, and they're all displayed on a G4 with part of the processing handled by an ATI Radeon GPU.
Right now I can (or could, if I had a G5 instead of a Mac mini) take that 64-bit source code (application, client-side UNIX/X11 libraries, and Xlib) compile it under Tiger, and have EXACTLY THE SAME 64-bit-native environment as I do under Tru64 UNIX.
On the other hand, if I were to go to a Windows box, I would have to go through every line of that code and find every place I'd used a "long" as an offset or an index into an array, and change it to "long long", because the "64-bit" version of windows uses a mixed 32-bit/64-bit model with 64-bit pointers and 32-bit integers. Why? Because Microsoft had to come up with a scheme that would let them link 64-bit applications with 32-bit libraries without having to port all the existing libraries to 32-bit, and unlike UNIX Windows doesn't use a clean client-server display interface.
The ONLY thing you can't do under Mac OS X is write applications that use Quartz directly, rather than through X11 or a client-server OpenGL mechanism. Which means you won't take the performance hit from making every structure larger (most twice as large) in code that doesn't actually benefit from the larger address space. Because there's no inherent performance boost to going to 64-bit code: the only reason it helps on Windows is the 64-bit instruction set has shed a lot of the junk in the grotty old Intel architecture, and at the same time quadrupled the size of the register file (twice as many registers, twice as wide). PPC doesn't have that handicap to worry about.
So.
For people who actually need it, Tiger is a BETTER 64-bit environment than Windows 2003/XP, because their existing code that they've been using (some for as long as a decade, already) is much much easier to port to it.
At least Microsoft doesn't have your testicles in a lime squeezer when it comes to hardware selection.
So what upgrade options does the Xbox have again?
I REALLY dislike Microsoft, if only because I fix computers for a living.
You must be thinking of HP or Dell or someone, there, Microsoft doesn't make computers... they make a game console, crummy keyboards, and some pretty nice optical mice.
I would think that assuming that web sites are safe is a pretty dangerous assumption.
If you can't assume websites are safe, that the next click on a link won't load an untrusted program into an application that was never designed fromthe ground up to handle untrusted data, then you really can't use the web at all. Because the fact is, any click on any site can take you to a page that contains potentially unsafe content. Even within a trusted entity's secure website: the website could have been compromised, someone might have figured out how to inject content through the feedback form, anything... so the browser's job is to make sure that you can't accidentally flinch the wrong way at an annoying dialog bug and let the spyware out of the sandbox.
You can still DELIBERATELY download and open it. If you want to take responsibility for that action... but clicking "OK" isnt enough to do that.
This isn't an arbitrary barrier, any more than your front door, the firewall between your engine and the passenger compartment of your car, or the fence running along the edge of a cliff is an arbitrary barrier. This is a natural place to put a door.
So, maybe there SHOULD be a nanny-interface. As long as I can turn it off, that's fine.
The "nanny interface" is the one that tells you "hey! you're downloading an application! that could be dangerous!". Yes, you should be able to turn it off, because it's not really keeping you from doing dangerous things... and of course you can't turn it off in Safari. But you can get a browser that doesn't need it...
Camino is what I'm using these days. It's an Apple-standard-interface version of the Mozilla/Gecko browser family.
Not only is Camino inherently safer here, but the Camino download manager provides JUST AS MUCH convenience as you get from automatic downloads with the nanny interface. On one case you click on the link, then you click "OK". In the other case you click on the link, then you click on the "open" button.
The difference? The "open" button is a deliberate request, it's not something that turns into a reflex action... because...
1. It's unique to the downloading operation. It's not something you also get when you "empty trash" and "move files on top of old versions" and every other time you are about to take an irrevocabe step.
2. It's not something you have to decide RIGHT THERE what to do to continue. You can leave the file in the download manager, there's no urgency.
3. There's more things you can do. You can open it, you can show it in Finder, you can copy its location to the clipboard, you can clear it because you want to get back to it later.
The whole process is deliberate, it's made of choice, not "hey! decide now! hard sell, baby, TAKE AN ACTION". MUCH better design, and JUST as convenient as Safari.
Is there really a substantive difference between downloading a file and saying "Yes, I want to run this" and downloading a file and double clicking on it?
Yes. It's the difference between accidentally buying a pallet of junk at an auction by waving your hand at the wrong time, and buying a pallet of junk at a surplus store by pointing to it and saying "I want to buy it".
It's hard for me to understand how you could have a powerful, flexible system that doesn't allow the user to do stuff by clicking on things.
You'll have to explain what you're getting at here. I haven't suggested that people shouldn't be allowed to "do stuff by clicking on things". I'm saying that the browser shouldn't interpret a click in a "sandboxed" environment as a request to move an untrusted document outside that environment and open it.
Clicking on links in a browser is something that is, normally, always a "safe" operation as far as your computer is concerned. The browser is sandboxed, as you mode from page to page the websites can sow you different serts of images and text, even quite sophisticated ones uring Flash or Java, but you can't normally have that take over your computer, any more than reading a book can make your head explode, or watching TV can set your end-tables on fire.
And that's important, because you can't trust people on the net not to want to set your end-tables on fire or explode your head.
So moving OUT of the "safe" environment into the "unsafe" environment should require an explicit action. If you're watching TV and someone comes to the door, you have to get up and go down to the door and let them in. You don't yell "yes, who is it" and have your house interpret that "yes" to mean "let them in".
Well, that's what a dialog box does in this situation. It doesn't make an unsafe operation safe, it just makes it one that can happen by mistake.
Sorry for the shouting, but I've been watching this slow motion train wreck roll itself out for about a year, since Apple failed to properly close the design flaw underlying the "help:" hole, which is another part of the same problem I see here.
When people are faced with dialog boxes when they do a routine operation saying "what is about to happen may be dangerous", then they pretty soon get in the habit of just clicking "yes" without thinking.
Do you want to delete this file? (click) (oh, hell)
Do you want to run this ActiveX control? (click) (damn)
I spent several years supporting Windows users, and every now and then one of them would come to me and say "I just did something stupid, I got this box, and it asked if I wanted to run something, and I said yes, and now I'm infected". And I'd go clean their PC up. And some of them, a few months later, would come to me again, "I'm sorry, I did it again"...
This was still pretty rare, for a long time, because I'd set up a policy back around 1997 that Internet Explorer and Outlook and every other application that used the MS HTML control was banned. So the only time these problems came up for many years was when someone was using IE against my instructions. A couple of years back, though, we got merged with the rest of the company and my policy was overridden by the parent's "IE only" policy. Then I started getting this regularly.
But, most users were using other browsers, like Netscape. And Netscape (and Firefox, mostly) doesn't have any kind of "auto run" mechanism. You have to explicitly download a file and run it. I still had a few people that did that, but I never had one do it twice, and even when most users were using Netscape it was IE and Outlook where the vast majority of my virus and spyware problems came from.
This is not a hard lesson to learn. Automatically opening safe files after you download them is dangerous. Automatically downloading them is more dangerous. Automatically downloading and installing them when they're not even "safe"? I've watched what happens when you allow that, EVEN WHEN you pop up a dialog box when you do it, and if Apple keeps this up, I'm going to have to treat Safari as the same kind of "Typhoid Mary" as Internet Explorer. It's not quite as bad, I suppose it's like going to work when you've got a contagious cold... it's still not what anyone would call appropriate behaviour.
What is the point of having a AllowFullAccess boolean if the developer can add it without any controls by the user?
None at all, and it wouldn't make any difference if the user could control it. Dashboard is not inherently sandboxed, and shouldn't be. It's an application environment, not a browser.
The real problem is still that Safari is treating Dashboard as "safe", when Dashboard is not "safe". Even if "open safe files after downloading" was a good idea, a Dashboard widget is NOT a safe file.
"Second, Mac OS X 10.4.1 completely fixes the the widget auto-installation issue by adding widgets to the items that Safari prompts for before a download is complete."
THIS DOES NOT FIX THE PROBLEM
Widgets are still autoinstalled by Safari when "open safe files" is turned on. PROMPTING BEFORE AUTOINSTALLING IS NOT ENOUGH. This is one of the first things Microsoft did to try and paper over ActiveX, and we can all see how successful that was.
I'm not a lawyer, but I haven't heard of any law that would make downloading music a fine. SERVING music downloads, though, is a different matter... and with peer-to-peer you're serving when you're downloading unless you're leeching.
If there's an actual case where they went after someone PURELY for downloading, not serving, I'd appreciate a correction.
So, anyway, the crime the RIAA is going after them for, really, is unrelated to how much it costs them to download music from Yahoo. It's how much all the people who downloaded the music FROM THEM would have paid... and if you're on a filesharing network that can be thousands of people... which even at $5/month comes to thousands of dollars.
The real problem with the Lisa was they didn't really have any apps other than the "Lisa Office System", and that was more like a single integrated office suite than separate applications, because the user interface libraries were developed as part of and in support of this package. The user interface toolkits started out far more primitive than the Mac's: they didn't really have much of a framework outside the Office System itself other than basic drawing primitives and support for overlapping clipping regions (windows).
They ended up developing a lot of important libraries like QuickDraw on the Lisa, but they never really brought them all together into anything like a graphical operating system. That's why the Mac, even though all it HAD was the GUI toolkit with barely enough "OS" under the covers to start the GUI up, quickly supplanted the Lisa. Not only was the Mac cheaper, but you didn't need to be a software god to program it.
Now, programming the original Mac OS was kind of like UNIX kernel programming with its relentless need to get back to GetNextEvent (the Mac's equivalent of kernel sleep()) lest the GUI freeze up. So I hate to think what Lisa programming must have been like if that was an improvement.
The Lisa's most important role was as the first development platform for the Mac, culminating in its short-lived reincarnation as the Mac XL.
I've been using a real 64-bit OS for over 10 years now, using a true 64-bit API, and all I can say about this issue is:
1. If you really need 64-bit, you know it.
If you just think 64-bit is all about speed, you're confused... the reason the 64-bit Alpha was fast and stayed at the front of the pack with far less effort than Intel had to go through (at least until it got Compaqted) was less the fact that it was 64-bit (in fact programs in 32-bit mode were often faster) than the fact that DEC was able to start with a clean slate and design a good fast CPU architecture without having loads of backwards compatibility to worry about.
The reason AMD's 64-bit stuff is fast is the same, they're able to shed a lot of the IA32 cruft and add a lot more register file space.
And that's why 64-bit Power PC doesn't give you the same boost, because it's already a pretty good CPU architecture, it doesn't have a need for a massive overhaul.
So unless you REALLY need 64 bit, and if you do you already know you need it and you know why you need it and you're not whinging about whether Apple's 64-bit is "real" or not because you're already using it, it doesn't matter if your 64-bit is real or not, because you don't need it and won't use it even if you have it.
2. If you think Windows is "real" 64-bit, think again.
Even the latest 64-bit Windows isn't using a pure 64-bit model, even in 64-bit mode. DEC went with a full 64-bit model that matched the native Alpha 64-bit register set, and most of the other UNIX systems went with 64-bit longs and 64-bit pointers, but Windows uses 32-bit longs and 64-bit pointers, and you need a special "long long" data type to do pointer and offset arithmetic. So, using code that actually addresses more than 4G of RAM on Windows is going to remain tricky for a while.
Apple uses the intermediate model, with 64-bit pointers, and both 64 and 32-bit integers (int and long). This requires a little more complexity than the Alpha 64-bit model, but it lets 64-bit programs that people are already using work without change. So while you can't call the 32-bit GUI libraries from 64-bit mode, most 64-bit code is server software or command-line batch applications that don't make GUI calls at all... and that'll just work on Tiger.
I know many G5 owners who had no clue until I told them that their G5 actually could not run 64-bit applications because OS-X did not support it.
The fact that they had no clue means they didn't need it, and the only advantage of the 64-bit hardware for them (like for virtually everyone else in the entire world, except for people who already knew about it because anyone who really needed it was on top of that kind of detail) was that it let them use more than 4G of physical RAM. shared among all their (32-bit and WAY less than 4G long) apps.
And from the very first the Powermac G5 supported up to 8G.
So for the only purpose that mattered to them, they already had a useful 64-bit system.
The people who ought to feel miffed are the ones who've already been using ILP64 or LP64 code for years, who will have to port it to the IL32P64 Windows mess.
Apple has stated that the reason their laptops remain at the resolution they do is so that they maintain a 100dpi resolution. So it is intentional. You can disagree with that if you like -- not many people need to run 15" screens at super-high resolutions, as they can often make text difficult to read.
No they don't. They make unscaled text difficult to read, but Apple has one of the best scalable text systems on the planet right now... so going from 100dpi to 120dpi means either 20% smaller text or 20% better quality text at small text sizes... which means your text is actually EASIER to read.
Apple has the best scalable text on the planet right now. In fact it's hard to really take advantage of it because you have to turn antialiasing off when you get down below about 10px, but if the screen was 120dpi you'd get 20%
The real crime here is that Apple would have even shipped a computer with a 4200rpm drive.
That's not a crime, but it is possibly excessively conservative design. The Mac mini is a bit of a thermal challenge as it is, and there's a lot of places they've really shortchanged performance to make it run on less power and thus need less cooling. I'm sure that's why the USB ports can't deliver full power, for example... the external powered hub I used gets noticably warmer when I have a pocket hard disk hooked up to it. It's possibly even why they went with the Radeon 9200, because the 9600SE isn't that much more expensive (and would have supported QE2d, dagnabbit).
Microsoft can take a tri-core G5 based CPU and put it a Video Game Console
We don't know anything about the Xbox CPU other than it's got 3 "G5" cores and it runs at 3.2 GHz. We do know that the "Cell" computer in the Playstation 3 will use a "G5" core, but we know a few other things about it that make it less exciting as a general purpose computer - it's got no L2 cache, for one thing - so you can't assume that the processor in the Xbox is similar to what Apple would need for a 3 GHz Powermac G5.
Remember, Apple's getting CPUs from IBM as well, and it's the speed of those CPUs that have been holding them back.
Most Mac users don't seem to distinguish between Appletalk and Appleshare unless they're complaining that Tiger doesn't support Appletalk and their old OS 9 file servers aren't up to doing Appleshare.:)
I'd hold off on the Minimate. Early reports indicate it runs hot enough to bother the Mac mini if you stack 'em. There's other enclosures like this coming out, including one with a temperature-controlled fan.
I use a Lacie hard drive, mostly because they have a really good reputation on the Mac web. It doesn't stack but it's cute enough that my mini hasn't kicked it out of bed yet.
I have a Dell keyboard and a Microsoft mouse plugged into my Mac mini. If that didn't cause a space-time vortex that sucked me screaming into the bowels of the underworld, I think you're OK.
I ran each benchmark a couple times until the results became fairy consistent between runs. The first run on each drive was noticeably different than the following ones, what I am publishing here is from one of the later runs.
He should have done a fresh boot before each run, I think, to make sure the unified buffer cache didn't hide some of the performance differences... especially if he had 512M or more of RAM in the mini. What does XBench do to compensate for caching?
I think the one addition to point out is that Dashboard will only honor requests in the code for certain methods of the widget object based on the security level specified in the plist.
Yeh, this is Dashboard's pseudo-sandbox. What I'm getting at is that this pseudo-snadbox doesn't actually provide any useful security, because most widgets require additional rights to function so allowing a widget those extra rights is a normal operation that someone is going to expect to do when running a widget. Additional granularity would just confuse the user and it doesn't really buy you anything unless you can genuinely distinguish capabilities that are "more safe". For example, there's no reason to distinguish "running an embedded Cocoa component" and "making a system() call" because both of these grant you full local-user control.
And it's amazing how little privilege it takes to start a security escalation chain. Unless you can rigorously define an intermediate sandbox that yu can prove provides an intermediate level of security it's best to just stick to a two-level approach: sandbox on or sandbox off.
A better security model... if you want one... would be for Dashboard to only run installed widgets, and for widgets that haven't been installed you'd just open them in a generic webcore app. So opening up a ".wdgt" bundle in Safari would open the widget in Safari with no access to Dashboard's extensions.
Mach in a different way then it is usually used, i.e. not as a microkernel with services running on top of it in user mode
You're mixing up two completely unrelated uses of the word "kernel" here. There's nothing in the microkernel model that says components have to run in any particular mode or space. The microkernel model is all about how components interact with each other, no matter what "mode" or "space" they run in. Try replacing the phrase "kernel mode" with "privileged mode". The 'externally visible' kernel is a higher level construct.
There are microkernels where the microkernel itself is only a few kilobytes long, and the whole distinction between "user mode" and "privileged mode" is implemented outside the microkernel. There are microkernels that don't even have a concept of "user mode", the whole OS and applications run in the equivalent of "the kernel".
Now you can argue that Mach isn't really a microkernel. A lot of people in the real-time industry (where microkernels aren't just some exotic concept, but a pretty normal way of building an OS) have been pretty dismissive of Mach from the start... 'How can it be a microkernel when its microkernel is bigger than my whole OS?' is a pretty typical attitude.
One example is the unified buffer cache, which ties directly into the mach vm layer.
Well, yeh. FreeBSD uses the Mach VM code too.
Mach is certainly used for more than bootstrapping the bsd subsystem.
I didn't say it wasn't. What I said was that the BSD subsystem is not just an emulation layer, it's a complete server that provides services throughout the system at every level. The boot process is the standard BSD model, with init calling the shots, running/etc/rc to kick off all the standard daemons and some which may be unique to Mach... but they're all created using the UNIX fork/exec mehanism rather than directly through Mach primitives.
Any time you put together a sentence with "Apple will never..." or "Apple knows that... is retarded" or any other construct that attempts to predict that Apple WON'T do something... you're setting yourself up.
Saying "Apple will never..." is a stretching excersize for fitting your foot in your mouth. For example:
But no, I suspect you're right that [the $500 iMac] is a hoax. Not because of logistics, but because Steve Jobs irrational antipathy to "ugly monitors on nice Macs" is too well known... he'd much rather force Apple users to put up with lousy monitors in pretty shells than lose face by backing down on something like this. -- Me, December 30, 2004
This was just before MWSF05 where, a year after Steve Jobs had "explained" why flash MP3 players were retarded, Apple introduced both the Mac mini and the iPod Shuffle. No, friend, I don't believe that there's anything Jobs or any other Apple spokesman could say that they wouldn't take back once they figure out a way to make it cool.
there was a ancient debate between Linus and that other guy about Micro- vs Macro-kernels, and guess what, Linus was right.
Only in the sense that if you can get a tiny team of hand-picked supermen led by a guy who's willing to build his own source code management system just to let him feed changes into the code base fast enough to keep things going, you can make a monolithic design deliver some of the benefits of a microkernel design, and still have the performance benefits of the monolithic design.
See, monolithic kernels give you decent performance "for free", because you automatically get a 1:1 relation between the number of threads dedicated to completing an operation in the kernel and the number of threads waiting on those operations. Modularity, asynchronous I/O, SMP, these things are hard, and every kernel component has to be written to a cooperative multitasking model.
Microkernels give you good modularity and asynchronous I/O and concurrency "for free", because I/O is always the responsibility of someone other than the calling task and no component locks more than the resources it needs itself. But every component is a potential bottleneck unless it's written with concurrency in mind so performance takes continual work.
The big problem with Minix was that that work was deliberately not done, because it was designed to be simple and easily understood. The reason that it had poor performance was not that it was a microkernel, but that it was a simplified one.
As for Mach, whether that was ever really a true microkernel is an open question. Can it be called "micro" if it was bigger than many complete kernels at the time. QNX's microkernel, on the other hand, was small enough to fit completely in the instruction cache on a 486... and that's the kind of thing you need to do when you're building a production microkernel instead of an academic one.
Slashdot Mirror
Can't find opensource.apple.com: No answer
So, if I said "babelfish is a great translator" you'd come back and say "that's not even a legal domain name"?
In my world though, moving our servers to the 64bit version of Windows took our server requirments to less than 1/5 the equivalent systems when running the 32bit version of Windows 2003 Server.
And this was because:
1. You redesigned all your services to use 64-bit large-address space code where you had previously been using read/write to access a large disk-based object through a 2G "windows".
2. Newer computers are generally faster than old ones, and Opteron's instruction set is faster than IA32 because of the slightly cleaner ABI and the larger register file.
3. You're running Oracle, and Oracle through utterly heroic measures has managed to take advantage of the "32-bit-segmented" mode of the Xeon to get option 1 working, so your speedup is a special case that most people can't take advantage of.
4. You don't know, and you don't care.
5. Something I haven't thought of.
the Application would have to broken up to have a 32bit interface and only use the 64bit code for intensive calculations.
And this is a problem... why? I mean, this is a completely normal way to build GUI applications. Every UNIX GUI application, except for a few videogames that use an SDL interface to the raw frame buffer on Linux, is client-server, and most high-performance ones use OpenGL as well so you have part of the application running in the client, part on the display server, and part in the GPU, and all three of these parts can be in different processors using different instruction sets. I mean right now I'm running UNIX GUI applications on a 64-bit Alpha, a Xeon running Linux, a 32-bit G4, and they're all displayed on a G4 with part of the processing handled by an ATI Radeon GPU.
Right now I can (or could, if I had a G5 instead of a Mac mini) take that 64-bit source code (application, client-side UNIX/X11 libraries, and Xlib) compile it under Tiger, and have EXACTLY THE SAME 64-bit-native environment as I do under Tru64 UNIX.
On the other hand, if I were to go to a Windows box, I would have to go through every line of that code and find every place I'd used a "long" as an offset or an index into an array, and change it to "long long", because the "64-bit" version of windows uses a mixed 32-bit/64-bit model with 64-bit pointers and 32-bit integers. Why? Because Microsoft had to come up with a scheme that would let them link 64-bit applications with 32-bit libraries without having to port all the existing libraries to 32-bit, and unlike UNIX Windows doesn't use a clean client-server display interface.
The ONLY thing you can't do under Mac OS X is write applications that use Quartz directly, rather than through X11 or a client-server OpenGL mechanism. Which means you won't take the performance hit from making every structure larger (most twice as large) in code that doesn't actually benefit from the larger address space. Because there's no inherent performance boost to going to 64-bit code: the only reason it helps on Windows is the 64-bit instruction set has shed a lot of the junk in the grotty old Intel architecture, and at the same time quadrupled the size of the register file (twice as many registers, twice as wide). PPC doesn't have that handicap to worry about.
So.
For people who actually need it, Tiger is a BETTER 64-bit environment than Windows 2003/XP, because their existing code that they've been using (some for as long as a decade, already) is much much easier to port to it.
At least Microsoft doesn't have your testicles in a lime squeezer when it comes to hardware selection.
So what upgrade options does the Xbox have again?
I REALLY dislike Microsoft, if only because I fix computers for a living.
You must be thinking of HP or Dell or someone, there, Microsoft doesn't make computers... they make a game console, crummy keyboards, and some pretty nice optical mice.
By all means, so long as I can have it back when I need it.
I would think that assuming that web sites are safe is a pretty dangerous assumption.
If you can't assume websites are safe, that the next click on a link won't load an untrusted program into an application that was never designed fromthe ground up to handle untrusted data, then you really can't use the web at all. Because the fact is, any click on any site can take you to a page that contains potentially unsafe content. Even within a trusted entity's secure website: the website could have been compromised, someone might have figured out how to inject content through the feedback form, anything... so the browser's job is to make sure that you can't accidentally flinch the wrong way at an annoying dialog bug and let the spyware out of the sandbox.
You can still DELIBERATELY download and open it. If you want to take responsibility for that action... but clicking "OK" isnt enough to do that.
This isn't an arbitrary barrier, any more than your front door, the firewall between your engine and the passenger compartment of your car, or the fence running along the edge of a cliff is an arbitrary barrier. This is a natural place to put a door.
So, maybe there SHOULD be a nanny-interface. As long as I can turn it off, that's fine.
The "nanny interface" is the one that tells you "hey! you're downloading an application! that could be dangerous!". Yes, you should be able to turn it off, because it's not really keeping you from doing dangerous things... and of course you can't turn it off in Safari. But you can get a browser that doesn't need it...
Camino is what I'm using these days. It's an Apple-standard-interface version of the Mozilla/Gecko browser family.
Not only is Camino inherently safer here, but the Camino download manager provides JUST AS MUCH convenience as you get from automatic downloads with the nanny interface. On one case you click on the link, then you click "OK". In the other case you click on the link, then you click on the "open" button.
The difference? The "open" button is a deliberate request, it's not something that turns into a reflex action... because...
1. It's unique to the downloading operation. It's not something you also get when you "empty trash" and "move files on top of old versions" and every other time you are about to take an irrevocabe step.
2. It's not something you have to decide RIGHT THERE what to do to continue. You can leave the file in the download manager, there's no urgency.
3. There's more things you can do. You can open it, you can show it in Finder, you can copy its location to the clipboard, you can clear it because you want to get back to it later.
The whole process is deliberate, it's made of choice, not "hey! decide now! hard sell, baby, TAKE AN ACTION". MUCH better design, and JUST as convenient as Safari.
Is there really a substantive difference between downloading a file and saying "Yes, I want to run this" and downloading a file and double clicking on it?
Yes. It's the difference between accidentally buying a pallet of junk at an auction by waving your hand at the wrong time, and buying a pallet of junk at a surplus store by pointing to it and saying "I want to buy it".
It's hard for me to understand how you could have a powerful, flexible system that doesn't allow the user to do stuff by clicking on things.
You'll have to explain what you're getting at here. I haven't suggested that people shouldn't be allowed to "do stuff by clicking on things". I'm saying that the browser shouldn't interpret a click in a "sandboxed" environment as a request to move an untrusted document outside that environment and open it.
Clicking on links in a browser is something that is, normally, always a "safe" operation as far as your computer is concerned. The browser is sandboxed, as you mode from page to page the websites can sow you different serts of images and text, even quite sophisticated ones uring Flash or Java, but you can't normally have that take over your computer, any more than reading a book can make your head explode, or watching TV can set your end-tables on fire.
And that's important, because you can't trust people on the net not to want to set your end-tables on fire or explode your head.
So moving OUT of the "safe" environment into the "unsafe" environment should require an explicit action. If you're watching TV and someone comes to the door, you have to get up and go down to the door and let them in. You don't yell "yes, who is it" and have your house interpret that "yes" to mean "let them in".
Well, that's what a dialog box does in this situation. It doesn't make an unsafe operation safe, it just makes it one that can happen by mistake.
Sorry for the shouting, but I've been watching this slow motion train wreck roll itself out for about a year, since Apple failed to properly close the design flaw underlying the "help:" hole, which is another part of the same problem I see here.
When people are faced with dialog boxes when they do a routine operation saying "what is about to happen may be dangerous", then they pretty soon get in the habit of just clicking "yes" without thinking.
Do you want to delete this file? (click) (oh, hell)
Do you want to run this ActiveX control? (click) (damn)
I spent several years supporting Windows users, and every now and then one of them would come to me and say "I just did something stupid, I got this box, and it asked if I wanted to run something, and I said yes, and now I'm infected". And I'd go clean their PC up. And some of them, a few months later, would come to me again, "I'm sorry, I did it again"...
This was still pretty rare, for a long time, because I'd set up a policy back around 1997 that Internet Explorer and Outlook and every other application that used the MS HTML control was banned. So the only time these problems came up for many years was when someone was using IE against my instructions. A couple of years back, though, we got merged with the rest of the company and my policy was overridden by the parent's "IE only" policy. Then I started getting this regularly.
But, most users were using other browsers, like Netscape. And Netscape (and Firefox, mostly) doesn't have any kind of "auto run" mechanism. You have to explicitly download a file and run it. I still had a few people that did that, but I never had one do it twice, and even when most users were using Netscape it was IE and Outlook where the vast majority of my virus and spyware problems came from.
This is not a hard lesson to learn. Automatically opening safe files after you download them is dangerous. Automatically downloading them is more dangerous. Automatically downloading and installing them when they're not even "safe"? I've watched what happens when you allow that, EVEN WHEN you pop up a dialog box when you do it, and if Apple keeps this up, I'm going to have to treat Safari as the same kind of "Typhoid Mary" as Internet Explorer. It's not quite as bad, I suppose it's like going to work when you've got a contagious cold... it's still not what anyone would call appropriate behaviour.
A previous thread on the same subject here.
What is the point of having a AllowFullAccess boolean if the developer can add it without any controls by the user?
None at all, and it wouldn't make any difference if the user could control it. Dashboard is not inherently sandboxed, and shouldn't be. It's an application environment, not a browser.
The real problem is still that Safari is treating Dashboard as "safe", when Dashboard is not "safe". Even if "open safe files after downloading" was a good idea, a Dashboard widget is NOT a safe file.
"Second, Mac OS X 10.4.1 completely fixes the the widget auto-installation issue by adding widgets to the items that Safari prompts for before a download is complete."
THIS DOES NOT FIX THE PROBLEM
Widgets are still autoinstalled by Safari when "open safe files" is turned on. PROMPTING BEFORE AUTOINSTALLING IS NOT ENOUGH. This is one of the first things Microsoft did to try and paper over ActiveX, and we can all see how successful that was.
I'm not a lawyer, but I haven't heard of any law that would make downloading music a fine. SERVING music downloads, though, is a different matter... and with peer-to-peer you're serving when you're downloading unless you're leeching.
If there's an actual case where they went after someone PURELY for downloading, not serving, I'd appreciate a correction.
So, anyway, the crime the RIAA is going after them for, really, is unrelated to how much it costs them to download music from Yahoo. It's how much all the people who downloaded the music FROM THEM would have paid... and if you're on a filesharing network that can be thousands of people... which even at $5/month comes to thousands of dollars.
The real problem with the Lisa was they didn't really have any apps other than the "Lisa Office System", and that was more like a single integrated office suite than separate applications, because the user interface libraries were developed as part of and in support of this package. The user interface toolkits started out far more primitive than the Mac's: they didn't really have much of a framework outside the Office System itself other than basic drawing primitives and support for overlapping clipping regions (windows).
They ended up developing a lot of important libraries like QuickDraw on the Lisa, but they never really brought them all together into anything like a graphical operating system. That's why the Mac, even though all it HAD was the GUI toolkit with barely enough "OS" under the covers to start the GUI up, quickly supplanted the Lisa. Not only was the Mac cheaper, but you didn't need to be a software god to program it.
Now, programming the original Mac OS was kind of like UNIX kernel programming with its relentless need to get back to GetNextEvent (the Mac's equivalent of kernel sleep()) lest the GUI freeze up. So I hate to think what Lisa programming must have been like if that was an improvement.
The Lisa's most important role was as the first development platform for the Mac, culminating in its short-lived reincarnation as the Mac XL.
I've been using a real 64-bit OS for over 10 years now, using a true 64-bit API, and all I can say about this issue is:
1. If you really need 64-bit, you know it.
If you just think 64-bit is all about speed, you're confused... the reason the 64-bit Alpha was fast and stayed at the front of the pack with far less effort than Intel had to go through (at least until it got Compaqted) was less the fact that it was 64-bit (in fact programs in 32-bit mode were often faster) than the fact that DEC was able to start with a clean slate and design a good fast CPU architecture without having loads of backwards compatibility to worry about.
The reason AMD's 64-bit stuff is fast is the same, they're able to shed a lot of the IA32 cruft and add a lot more register file space.
And that's why 64-bit Power PC doesn't give you the same boost, because it's already a pretty good CPU architecture, it doesn't have a need for a massive overhaul.
So unless you REALLY need 64 bit, and if you do you already know you need it and you know why you need it and you're not whinging about whether Apple's 64-bit is "real" or not because you're already using it, it doesn't matter if your 64-bit is real or not, because you don't need it and won't use it even if you have it.
2. If you think Windows is "real" 64-bit, think again.
Even the latest 64-bit Windows isn't using a pure 64-bit model, even in 64-bit mode. DEC went with a full 64-bit model that matched the native Alpha 64-bit register set, and most of the other UNIX systems went with 64-bit longs and 64-bit pointers, but Windows uses 32-bit longs and 64-bit pointers, and you need a special "long long" data type to do pointer and offset arithmetic. So, using code that actually addresses more than 4G of RAM on Windows is going to remain tricky for a while.
Apple uses the intermediate model, with 64-bit pointers, and both 64 and 32-bit integers (int and long). This requires a little more complexity than the Alpha 64-bit model, but it lets 64-bit programs that people are already using work without change. So while you can't call the 32-bit GUI libraries from 64-bit mode, most 64-bit code is server software or command-line batch applications that don't make GUI calls at all... and that'll just work on Tiger.
I know many G5 owners who had no clue until I told them that their G5 actually could not run 64-bit applications because OS-X did not support it.
The fact that they had no clue means they didn't need it, and the only advantage of the 64-bit hardware for them (like for virtually everyone else in the entire world, except for people who already knew about it because anyone who really needed it was on top of that kind of detail) was that it let them use more than 4G of physical RAM. shared among all their (32-bit and WAY less than 4G long) apps.
And from the very first the Powermac G5 supported up to 8G.
So for the only purpose that mattered to them, they already had a useful 64-bit system.
The people who ought to feel miffed are the ones who've already been using ILP64 or LP64 code for years, who will have to port it to the IL32P64 Windows mess.
Apple has stated that the reason their laptops remain at the resolution they do is so that they maintain a 100dpi resolution. So it is intentional. You can disagree with that if you like -- not many people need to run 15" screens at super-high resolutions, as they can often make text difficult to read.
No they don't. They make unscaled text difficult to read, but Apple has one of the best scalable text systems on the planet right now... so going from 100dpi to 120dpi means either 20% smaller text or 20% better quality text at small text sizes... which means your text is actually EASIER to read.
Apple has the best scalable text on the planet right now. In fact it's hard to really take advantage of it because you have to turn antialiasing off when you get down below about 10px, but if the screen was 120dpi you'd get 20%
What enclosure would people suggest for a DVD. I'm siding with Firewire...
Firewire. Or maybe Firewire. If you can, get Firewire. Otherwise, Firewire.
The real crime here is that Apple would have even shipped a computer with a 4200rpm drive.
That's not a crime, but it is possibly excessively conservative design. The Mac mini is a bit of a thermal challenge as it is, and there's a lot of places they've really shortchanged performance to make it run on less power and thus need less cooling. I'm sure that's why the USB ports can't deliver full power, for example... the external powered hub I used gets noticably warmer when I have a pocket hard disk hooked up to it. It's possibly even why they went with the Radeon 9200, because the 9600SE isn't that much more expensive (and would have supported QE2d, dagnabbit).
Microsoft can take a tri-core G5 based CPU and put it a Video Game Console
We don't know anything about the Xbox CPU other than it's got 3 "G5" cores and it runs at 3.2 GHz. We do know that the "Cell" computer in the Playstation 3 will use a "G5" core, but we know a few other things about it that make it less exciting as a general purpose computer - it's got no L2 cache, for one thing - so you can't assume that the processor in the Xbox is similar to what Apple would need for a 3 GHz Powermac G5.
Remember, Apple's getting CPUs from IBM as well, and it's the speed of those CPUs that have been holding them back.
Most Mac users don't seem to distinguish between Appletalk and Appleshare unless they're complaining that Tiger doesn't support Appletalk and their old OS 9 file servers aren't up to doing Appleshare. :)
I'd hold off on the Minimate. Early reports indicate it runs hot enough to bother the Mac mini if you stack 'em. There's other enclosures like this coming out, including one with a temperature-controlled fan.
I use a Lacie hard drive, mostly because they have a really good reputation on the Mac web. It doesn't stack but it's cute enough that my mini hasn't kicked it out of bed yet.
I have a Dell keyboard and a Microsoft mouse plugged into my Mac mini. If that didn't cause a space-time vortex that sucked me screaming into the bowels of the underworld, I think you're OK.
I ran each benchmark a couple times until the results became fairy consistent between runs. The first run on each drive was noticeably different than the following ones, what I am publishing here is from one of the later runs.
He should have done a fresh boot before each run, I think, to make sure the unified buffer cache didn't hide some of the performance differences... especially if he had 512M or more of RAM in the mini. What does XBench do to compensate for caching?
I think the one addition to point out is that Dashboard will only honor requests in the code for certain methods of the widget object based on the security level specified in the plist.
Yeh, this is Dashboard's pseudo-sandbox. What I'm getting at is that this pseudo-snadbox doesn't actually provide any useful security, because most widgets require additional rights to function so allowing a widget those extra rights is a normal operation that someone is going to expect to do when running a widget. Additional granularity would just confuse the user and it doesn't really buy you anything unless you can genuinely distinguish capabilities that are "more safe". For example, there's no reason to distinguish "running an embedded Cocoa component" and "making a system() call" because both of these grant you full local-user control.
And it's amazing how little privilege it takes to start a security escalation chain. Unless you can rigorously define an intermediate sandbox that yu can prove provides an intermediate level of security it's best to just stick to a two-level approach: sandbox on or sandbox off.
A better security model... if you want one... would be for Dashboard to only run installed widgets, and for widgets that haven't been installed you'd just open them in a generic webcore app. So opening up a ".wdgt" bundle in Safari would open the widget in Safari with no access to Dashboard's extensions.
Mach in a different way then it is usually used, i.e. not as a microkernel with services running on top of it in user mode
You're mixing up two completely unrelated uses of the word "kernel" here. There's nothing in the microkernel model that says components have to run in any particular mode or space. The microkernel model is all about how components interact with each other, no matter what "mode" or "space" they run in. Try replacing the phrase "kernel mode" with "privileged mode". The 'externally visible' kernel is a higher level construct.
There are microkernels where the microkernel itself is only a few kilobytes long, and the whole distinction between "user mode" and "privileged mode" is implemented outside the microkernel. There are microkernels that don't even have a concept of "user mode", the whole OS and applications run in the equivalent of "the kernel".
Now you can argue that Mach isn't really a microkernel. A lot of people in the real-time industry (where microkernels aren't just some exotic concept, but a pretty normal way of building an OS) have been pretty dismissive of Mach from the start... 'How can it be a microkernel when its microkernel is bigger than my whole OS?' is a pretty typical attitude.
One example is the unified buffer cache, which ties directly into the mach vm layer.
/etc/rc to kick off all the standard daemons and some which may be unique to Mach... but they're all created using the UNIX fork/exec mehanism rather than directly through Mach primitives.
Well, yeh. FreeBSD uses the Mach VM code too.
Mach is certainly used for more than bootstrapping the bsd subsystem.
I didn't say it wasn't. What I said was that the BSD subsystem is not just an emulation layer, it's a complete server that provides services throughout the system at every level. The boot process is the standard BSD model, with init calling the shots, running
Saying "Apple will never..." is a stretching excersize for fitting your foot in your mouth. For example:
This was just before MWSF05 where, a year after Steve Jobs had "explained" why flash MP3 players were retarded, Apple introduced both the Mac mini and the iPod Shuffle. No, friend, I don't believe that there's anything Jobs or any other Apple spokesman could say that they wouldn't take back once they figure out a way to make it cool.
there was a ancient debate between Linus and that other guy about Micro- vs Macro-kernels, and guess what, Linus was right.
Only in the sense that if you can get a tiny team of hand-picked supermen led by a guy who's willing to build his own source code management system just to let him feed changes into the code base fast enough to keep things going, you can make a monolithic design deliver some of the benefits of a microkernel design, and still have the performance benefits of the monolithic design.
See, monolithic kernels give you decent performance "for free", because you automatically get a 1:1 relation between the number of threads dedicated to completing an operation in the kernel and the number of threads waiting on those operations. Modularity, asynchronous I/O, SMP, these things are hard, and every kernel component has to be written to a cooperative multitasking model.
Microkernels give you good modularity and asynchronous I/O and concurrency "for free", because I/O is always the responsibility of someone other than the calling task and no component locks more than the resources it needs itself. But every component is a potential bottleneck unless it's written with concurrency in mind so performance takes continual work.
The big problem with Minix was that that work was deliberately not done, because it was designed to be simple and easily understood. The reason that it had poor performance was not that it was a microkernel, but that it was a simplified one.
As for Mach, whether that was ever really a true microkernel is an open question. Can it be called "micro" if it was bigger than many complete kernels at the time. QNX's microkernel, on the other hand, was small enough to fit completely in the instruction cache on a 486... and that's the kind of thing you need to do when you're building a production microkernel instead of an academic one.