Can this explain Action at a Distance? (Particles separated by meters [of late] behave identically)
that's all covered in the original paper.
Can we create a situation where a quantum particle has to swap universes? That would be the killer proof
I don't believe that the EWG hypothesis allows this.
Folks have been working on reducing String Theory from 26 dimension to 11-10 (sorry, I haven't kept up). Could the high-dimensional strings be the manifestation of the "bushes"?
No, the bushes aren't in a physical dimension. "Bush" is just a way to visualize the probabilities of different states of the system.
Is it possible to send Gravity into a parallel universe around an object, thereby creating null gravity?
No. You're thinking of the wrong Greg Egan novel. We're in Quarantine, not Diaspora.
I thought this outcome was an obvious result of the original EWG model. Whether the "collapse of the wave function" is a real effect (in the Copenhagen interpretation) or a side effect of the way our measurement devices (including our senses and conscious minds) work, the uncollapsed (unobserved) state vector produces the correct results after the collapse... there's no reason to assume that this would magically change if the collapse was "held off" indefinitely and the measurement was just performed in effect "in parallel" across multiple states.
That is, it would be headline news (well, for a certain kind of paper) if this study produced any other result.
What exactly am I missing?
Also, this doesn't "prove the multiple universe model", it just confirms that it's consistent with observation, but that's kind of the point of the model.
I couldn't disagree more - that's exactly what they're doing and will continue to do - they run almost the same software after all.
I guess we'll have to disagree on this one.
If they were trying to make them do the same job (ie, Palm-Sized PC/Pocket PC/Tablet PC... running different operating systems but all general purpose computers), then I would say so. But Apple is very clearly, it seems to me, distinguishing the iPhone/iPod from the Mac.
The iPhone is NOT "the new Mac". You seem to want to make it the new Mac, you want them to release an SDK for it, turn it into a "Pocket Mac". They don't want to do that, and have said so in no uncertain terms. They could turn that decision around, god knows they've given us whiplash of the blogosphere often enough, but right now that's NOT the course they've laid out.
The bottom line for me is that OS X is just another UNIX variant, like Linux, BSD, Solaris, or Xenix. It can be used for embedded systems or mainframes and everything in between. Using it as an embedded system doesn't signal a change in policy any more than switching to an aluminum case does.
Personally, I would love to see Apple put OS X up against Windows NT, ship a portable version for generic PCs, and ship an embedded OS X SDK for people to use in handhelds, and go so far beyond what you're looking for that it's over the event horizon. But it's not going to happen any time soon.
That's true for any appliance. You don't complain that you're locked in to your TV, or your refrigerator, or your toaster, even when they have software in them. The thing is that once you have bought a refrigerator, and you need to get a new one, you're not locked in to getting one that's compatible, that runs the same software.
The real fear here (and this is voiced in the article), is that in 10 years, when the OS X platform is mostly about mobile devices, and there are 10 million iPhones to each 1 million macs (this day will come), only Apple will control everything about these phones, and all the 3rd party developers will have to find some other platform to use, and customers will have to take what they're given, or look elsewhere.
If he means that Apple may abandon the Mac, because the iPhone and ipod are making so much money and the Mac is a liability, well, that's possible. And that's possible whether the iPhone is open or closed, and whether the iPhone is based on OS X or Windows CE. The iPhone is not a Macintosh. Just because it's running similar software, it's a different kind of device.
It's 10 years now since Microsoft started putting out Windows based handhelds. There's hardly any overlap at all between them and the Windows desktop, even though Microsoft has been trying hard to push full blown Windows NT into the handheld world. They're different kinds of devices.
All it would take from Apple would be a simple statement that the SDK is coming next year, and people should be patient till then.
You're assuming that Apple intends on there being an SDK. I don't expect so, any more. Apple is not interested in blurring the line between handhelds and desktops. After all, look how well that's worked for Microsoft.
I think Shipley rightly feels if no-one speaks out, then Jobs will think it's fine to continue down this path - perhaps even try to switch the entire OS X platform to a closed one like the iPhone, and to hell with the developers (they've said that enough times : ).
I think that Apple would have to do a lot more than introduce a new iPod (whether it's a phone or not) to make me concerned that they are headed down the path of a "sealed Mac". They may have said things like that, but when the developers dug in their heels and refused to go with Yellow Box, Rhapsody went on the shelf, Carbon came out, and OS 9, and what became OS X was delayed for years while they redesigned it to accommodate Adobe. But that's on the desktop, where they HAVE developers. Not in the handheld market, where they've already dumped them. So I don't think that ANYONE just "speaking out" is going to make Steve listen. They'd still be selling Newtons if that would work.
Now if Wil were to say that he was going to recode Delicious Monster in C# for Mono and.NET so it would run on Windows and Linux, and abandon the Macintosh, if Steve didn't open up the iPhone, they may think he's really crazy and they won't listen. And if two developers, two developers do it, in harmony, they may think they're both crazy and they won't listen to either of them. And three developers do it, three, can you imagine, maybe Adobe could get involved again, they may think it's an organization. And can you, can you imagine fifty developers, I said fifty developers holding pulling up stakes because they want an iPhone SDK. And friends they may thinks it's a movement.
The main problem is - there is no device like this out there, and no prospect of one in the near future, so we have nowhere to jump ship to if Apple gets worse.
Oh, you're not worried about the Mac after all. You just want to make the iPhone into a smartphone. Well, friend, Apple has only made ONE handheld device that was open, and that was the Newton, and that was a disaster. It had potential, but it was premature... the hardware wasn't there yet... but Apple has been wary of the whole programmable handheld market since. This isn't a new thing, it's just business as usual.
I mean, just because Apple makes a product, that doesn't mean you need to get one. If the iPhone provides what you need better than the alternatives, and you don't need what it doesn't provide... go for it. If it doesn't... get something else.
There's no "platform lock-in" to the iPhone. If there was an iPhone SDK, there would be, but as it is if you don't have an iPhone you can get another phone that can still use all the same third-party content you could if you had one, and if you do you aren't locked into it. This is a different kind of lockin-in, and it's got nothing to do with developers.
On the iPod...
Now we see that iPod owners who upgrade to a newer iPod must re-buy the games they've already bought, because the new iPods are incompatible with the old. No credit given for having already bought an identical game.
Is he talking about games produced by Apple, or games produced by third parties? I don't know, I never bought games for my iPod. I never even considered buying games for my iPod. Why? Because it was obviously a closed system from the start.
But I did buy some software for my Palm, and had to re-buy some of it when I got a newer PalmOS device, because the older games didn't handle the new screen size. That's not Palm's fault, and I don't blame them for that (and not just because there's enough well-earned blame landing on them as it is).
And I'm certainly not going to *create* a platform lock-in for them by buying an iPhone and crack into it.
What should Steve do? Well, for starters, give up on trying to control everything.
Oh, I can only agree, but Steve isn't going to do that, so my recommendation is to stick to the Mac, ignore the 'appliance' products, and have an exit strategy so you can jump ship if Apple decides they're going to get serious about making the Mac an appliance again. That way we'll never have to put up with 1984 being just like 1984.
In the meantime, be picky.
Apple needs to be able to say, "Look, NBC, you want to be dumb-asses and try to sell people crap they don't want, fine -- we're still going to sell iPods that'll play your programs, we just won't sell your programs on the nicest internet store in the world. Your loss, suckers, call us when you change your mind."
I don't think Apple can say that. Because you will only be able to download those videos to your iPod on Windows: We're Sorry the requested download is unavailable. Downloads are only available to users located in the United States that have a Microsoft operating system and Internet Explorer web browser. Please check back soon for other offers.
Now *there* is your *platform* lock in.
I don't write programs for Apple because I worship Apple. I write programs for them because they have the best development environment
Don't write programs for Apple. Write programs for Macintosh. You can't write programs for Apple's appliances.
I agree with you, they should make it possible, it wouldn't even be that hard... it'd just be another target option for XCode.
But Apple's decided they're not interested in selling iAppliances to me, so I'm not going to get one.
Windows has a number of components with APIs that are impossible, even in theory, to use securely with untrusted content, and for which no alternative can be expected to be available to a Windows application. This is different from "any operating system can have a buffer overflow".
I've listed a few here and as I said in another message recently I'm absolutely appalled that people are still making up excuses for fundamental design flaws that should have been fixed a decade ago. And all these flaws are still in Vista, all the same components with the same APIs... and putting your easily exploited browser inside a leaky sandbox to "mitigate" the damage is like depending on the rhythm method to guard against AIDS. Not only is it unreliable, but if someone can compromise IE through the HTML control they don't *need* to get out of it to steal your credit card numbers and bank account passwords from a form sniffer.
Security is like sex, once you're penetrated you're ****ed.
As for the popularity argument... even in markets where Microsoft is in a minority they have still carried an inordinate percentage of the exploits. It's not because Windows is "popular", it's because Windows security is "badly designed".
* Security zones should be labelled "insecurity zones". * No other OS *requires* a firewall simply to shut off access to essential internal services from the internet. NONE. * Having to use the equivalent of 'system' to run applications from a browser? You gotta be kidding.
And that's just the high profile ones, the ones that have been exploited routinely. And what happens when someone finds a vulnerability? They blame the victim, arguing "yahoo instant messenger" should have "sanitized" third party HTML before passing it to the HTML control (for one recent example). Sanitized? Sanitizing a document you're passing to a turing-complete interpreter is equivalent to solving the halting problem. No, you idiots, they couldn't have "sanitized" it... Microsoft should have provided an API for calling the HTML control that didn't require "sanitization". No other bleeding HTML display engine out there defaults to granting documents full local user rights unless it guesses they're not in the "trusted zone".
HELLO, PEOPLE, LET'S HAVE SOME BLOODY SANITY HERE.
Security mechanism MUST 'fail closed'. Not 'half open' (like Vista's reduced permissions scheme) or 'full open' (like security zones).
I despair, really I do. What the HELL are people learning in college these days?
The iPhone has a huge margin with or without the price drop. Only taking 30% margin instead of 50% (or whatever the figures are, they're around that order of magnitude) isn't "fire sale" pricing.
Not quite... shaders are used for faking surface properties that you don't want to do with actual geometry.
Yep, and you may still want to do that with raytracing... polygons are cheaper for a raytracer, but they're not free. The biggest bottleneck for raytracing is memory bandwidth, and it's still possible to choke it with polygons. It's not a magic wand.
I think there have been some CG productions that have rendered hair as individual strands.
Yes, it's possible, but they don't have to do it in realtime.
1. Outlook doesn't use the standard HTML control for rendering, it uses a separate control from Microsoft Word. Perhaps even Microsoft has realized the standard Microsoft HTML control is inherently insecure, but that doesn't help anyone else, because it's the only one that's universally available in all Windows systems, and it's the one Microsoft themselves use for everything else.
2. Parsing command-line application arguments is a huge hole. Users don't use the command line much, but programs call other programs that way all the time. There have been at least two exploits I know of in the past few months taking advantage of command line parsing.
3. You don't need a firewall at all on any modern BSD- or Linux-based system unless you run public services. Some systems come with services on by default, but there's plenty of "secure as shipped" systems available. If there's no service listening at a port, there's no way to attack through that port. If all TCP based services required locally only listen to localhost, there's nothing exposed for a firewall to protect. And on top of that Windows opens up all kinds of ports: the old Lan Manager ports, SMS, Messenger service,... you don't have to be running a server to have your ass hanging out, and none of these services are designed to run bound to localhost only.
Shaders are used for defining surface properties. I don't think vertex shaders at least would completely go away.
Do you see an efficient way to do things like hair in a real-time raytraced scene without some kind of program in the GPU? Converting the hair to polygons would be insane.
No, I've been sounding the alarm for a decade now. I've yet to see any evidence that Microsoft has made any serious attempt at fixing the fundamental design flaws that were already making it the prime target for malicious software in 1997.
win32 has been deprecated and sandboxed out for compat
If it was sandboxed it would be completely safe to download and run a hostile Win32 application under Vista, with no chance of damage to your OS, local content, etcetera. A sandbox that doesn't actually prevent access outside the sandbox is no sandbox at all. A sandbox that has everything that actually matters to the user inside it is no sandbox at all.
Win32 remains the basic Windows API in Vista. Until Microsoft fixes the APIs that already exist, and accepts the pushback from developers and users as a necessary cost of security, all they're doing is applying bandaids.
The HTML control: Having the HTML control provide a mechanism to execute code in a document with local user permissions at all is unacceptable. Given that exists, the "security zones" mechanism to control access to it fails "open", not "closed".
Program execution: The application being called is responsible for parsing the command line into components. Microsoft themselves have admitted it is impossible for an application to completely sanitize a command line in the general case, even where the command line is specified by an API.
Network servers: There is no general mechanism to control the binding of services to specific interfaces, which forces you to use firewalls, which would otherwise be a second layer of defense, to become the only way to prevent external access to internal services using TCP.
The fundamental security flaws in the APIs that Windows has been burdened with are still there. They're not going to go away, if Microsoft is still keeping them there after 10 years of vigorous exploitation. Adding more "mitigating factors" to try and reduce the danger once your system is penetrated through one of them is useful, yes, but the bottom line is still the same... security is like sex... once you're penetrated you're ****ed.
First, these licenses don't look bad to me. I really need more information about what the OSI's objections are.
Second... having an open source license isn't anything like the whole of the story. In fact, open source itself is only half the story.
Open Systems is at least as important as open source. Open systems means interfaces, APIs, protocols, and soon designed for interoperability, openly documented, and not under any single vendor's control. Samba is open source, but it's not implementing an open systems protocol because Jeremy Allison pretty much has to implement whatever Microsoft does. Heck, GCC has gone through periods where it was as proprietary as any Microsoft product, with all kinds of custom extensions that provided a barrier to entry for anyone who wasn't GCC or wasn't using GCC.
Microsoft's track record with open systems has been pretty bloody bad since long before the GPL was drafted.
When they started getting gung-ho about POSIX, that looked like a major turnaround, but the result was a POSIX implementation that was deliberately useless. They embraced open systems just enough to get NT into government purchases, and throttled it.
So let's see what they do *with* these licenses, before we get excited.
There would need to be some level of OpenGL emulation, I would think.
Let's think about what "good results" would mean, using the level of investment currently applied to rasterization.
The SaarCOR design gets 7-8M rays per second with an FPGA with 6M programmable gates. A good GPU may have 600M transistors... with things like multi-gate transistors I don't know exactly how you'd compare them, but let's be conservative and assume it's 1:1... so with 100 times the component budget, and maybe 8-10 times the clock speed, you should be able to implement a heck of a raytracer in hardware if you're nVidia or ATI. Or, for that matter, Intel... who has (one must admit) pretty damn good processor technology.:) I suspect that if you can get data in there fast enough you could blow past a billion rays a second without even trying, since raytracing performance scales up pretty much linearly with the number of processors.
The kind of hardware needed to run raytracing really fast is well understood, and it doesn't really look like today's GPUs or like intel's CPUs, though even today you can get better results if you take advantage of the GPU as well. If ATI or nVidia doesn't come up with a hardware raytracing GPU someone else will. It's a pity that Intel doesn't seem to be interested in working on that angle.
Here's an article I've dug out of the Wayback machine and cleaned up, Raytracing vs Rasterization. Phillip Slusallek's home page is here, and you can follow that to SaarCOR and OpenRT. They built a prototype RPU (R for raytracing) that at 66 MHz was comparable in performance to a 2.6 GHz P4. The video is pretty impressive, considering how slow the hardware is.
One of the benefits of raytracing is that it can render real curved surfaces, including NURBS and volumetric surfaces: without taking advantage of this aspect of the technology, would we really see much visual benefit?
Sure. Even without the obvious things you're pooh-poohing like reflection and refraction (and raytracing can produce good results for these on curved surfaces), you get universal shadowing (including self-shadowing, the lack of which really stands out for me in even the best rasterized images), far better shading and bump-mapping, and better illumination... and reduced development costs because so many things that are handcrafted now fall out of the technology.
Look at the second image. Look at the guy in the background. Look how his body beneath the gun is shadowed. You're never going to get that kind of effect from rasterizing. And that makes things look a lot more "plasticky" to me than sharp edged shadows do.
Open source licenses need to be compatible with other licenses to get approved now?
In general, incompatibility with other open source licenses is considered a bad thing, yes. If they are in fact "maximally incompatible" I would say that's a problem. On the other hand, I would like to see what they specifically claim are incompatibilities. I'm not sure that I see any showstoppers.
As long as it is possible for the WM to ignore the app (e.g., in cases where the user has set specific settings for that app in the WM configurations), then I don't see any reason why window managers shouldn't be able to support that.
Um, that's pretty much a paraphrase of what I've been saying. That the protocol needs to extended to allow windows to be declared specifically as the kind of tightly dependent windows I'm talking about. Because right now there doesn't seem to be a way to say that... simply making them child windows doesn't carry the same implications or there wouldn't be any perceived need for applications to override the WM.
Yes, because EVERY widely-used OS must be a Unix variant
I didn't say "best", I said "easiest". As I noted, they already have the code implemented and working in NT, in the POSIX subsystem.
Also, "becoming a UNIX based system" doesn't mean becoming a UNIX variant. There's nothing fundamentally wrong with the NT kernel on the desktop and (again) as I noted they have the code, they could expose as much or as little of it as they needed.
In addition, I didn't say "must". The very next paragraph presented the alternative of creating a new API that avoided the problems of the current ones but still worked for traditional command line programs, and deprecating the use of the current API for launching programs. While it would be best for people who write portable code if this was based on the UNIX "exec" call, that's certainly not a requirement.
did you notice that NONE of the problems you talked about have anything at all to do with whether an OS is built on top of Unix or NT or whatever?
Actually they do.
First, when launching a command line program under Windows the parameters are parsed into options and file names by the called program, not the calling program. In UNIX, this operation is performed by the calling program, so it can unambiguously pass strings containing quotes and other metacharacters to the called program without having to guess how they will be broken up into words. There have been a steady stream of exploits that take advantage of this design flaw.
Secondly, program in UNIX universally inherit a lot of context from the parent, including open file descriptors. This allows a network superserver (like inetd on UNIX) to manage the connections for network services without having to have each application independently provide their own API and configuration tools to control the ports they listen to. This is not part of the NT API... first, because open files and sockets are not the same kinds of objects, and second, because the process hierarchy in NT is convention rather than something built in to the system.
Both of these problems would be solved by deprecating CMD.EXE and the old DOS-derived Windows command line API, and the split between sockets and files that's the heritage of the old Lachman Winsock library, and going to a UNIX API for files and processes. Obviously there are other ways to do the same thing, but unless Microsoft actually implements one and takes steps to convert everything over to one that's kind of academic.
Now this isn't the same thing as having the OS "built on top of UNIX", but that's not what I said. There are many UNIX-based operating systems that are built on quite different kernels and with quite different underlying designs... some which are proud of their membership UNIX family while clearly being a different kind of OS, like QNX and BeOS, and others that keep their UNIX roots at arms length and the APIs partitioned off in a separate subsystem, like Windows NT. Windows already has an enormous amount of such indirect inheritence from UNIX thanks to Microsoft's aborted plan to merge MS-DOS and Xenix (this started with MS-DOS version 2). Which is precisely WHY this would be "the easiest solution".
Not the only. Maybe not even the best. But certainly the easiest.
The third of the main points I brought up - the HTML control - wouldn't automatically be solved by this design, but this comment was addressing the second half of my message (starting with "There are other problems, too.") Obviously the flaws in the HTML control could be cloned in UNIX. Apple has managed to copy one of them, unfortunately, and some have been carried forward into the design of.NET and I'm concerned with the possibility of them resurfacing in Mono and Moonlight.
I actually DO agree that having zero security holes in any software as large as Windows (or Linux) is an unrealistic goal.
That's not what they're being asked for. What they're being asked for is for systematic holes to be eliminated, so they don't have to keep being patched over and over again. I've listed some of the systematic holes in the design that they keep getting bit by in the message I posted just before yours.
The thing that really bothers me is that people are accepting the argument that holes Microsoft created are not Microsoft's fault. People are blaming applications that didn't sanitize untrusted content before passing it to insecure APIs, rather than blaming Microsoft for not providing a secure API they could use instead.
The biggest problem is, of course, the HTML control.
Until Microsoft abandons the entire "security zone" model and makes the HTML control default to a secure or "closed" state completely under the management of the calling application Windows security will never be anything but a joke. The recent hole in Yahoo Instant Messenger, for example, is primarily Microsoft's fault... because the "security zones" should not be able to "fail open". Blaming Yahoo for not 'sanitizing' the input is nuts.
No other HTML rendering library works this way. The two leading alternatives... Mozilla's Gecko and KDE's KHTML (and thus Apple's Webcore)... both implement a closed sandbox. If an application wants the page to have more capability, it must explicitly install hooks to grant it that capability. This way when an application renders a page using Gecko or KHTML there's no possibility of there being prepared holes to attack. In addition, when they DO install a controlled hole in the sandbox, they know that they're the only agency doing so... there's no concerns about some insecure ActiveX control in the system becoming an avenue of attack.
Until Microsoft completely changes the API for the HTML control they won't solve their image problem, and they shouldn't expect to... because until they do this, they have a problem and the image only reflects that.
ActiveX use in the HTML control, of course, is completely insane. Given all the layers of bandaids and patches and dialogs and settings and security levels wrapped around them, it's actually less effort to explicitly install a plugin than to open IE up to the point where you can use a "trusted" ActiveX control. They need to deprecate and eventually eliminate this.
There are other problems, too. Applications have to parse command lines completely, using their own code to break them up into arguments and perform wildcard expansion. Both OS X and Linux use the UNIX "exec" call, which doesn't require the application to add this additional evaluation step. Many of the "URI" related holes found in applications on Windows... including several recent ones involving IE, Firefox, and Second Life... are due to this flaw in Microsoft's APIs.
There's a second flaw in their URI handlers, and that is the inability to separate internal handlers that may expose more powerful capabilities than a sandboxed object should have access to with the ones that are designed for use by untrusted documents. The 'patch' to fix this is to try and sanitise the list of URI handlers that each application will use. This, like any other "sanitization-based" approach, is inherently flawed. They need to create a second registry that only supposedly secure applications will use... and then they won't need to worry about web pages containing links to ".CHM" files.
(Apple, by the way, has copied this flaw from Microsoft. But at least they don't share the rest of the burden)
The lack of a standard mechanism to bind network services to specific interfaces is a third problem. In UNIX most network services have traditionally been run from inetd, so if you replace inetd with something like xinetd or tcp wrappers you can prevent services from listening to anything but the local interface "localhost". This means that a firewall on UNIX is an extra defense, where on Windows it's the only way to keep insecure protocols from accepting connections from external sources.
For Microsoft to get the same reputation for security that UNIX based systems have earned, it will have to correct these flaws. The easiest way, perhaps, would be for it to BECOME a UNIX-based system. It wouldn't take much, so much of the API is already inherited from Microsoft's one-time infatuation with UNIX, and they ship a subset of teh UNIX API with Windows in the POSIX subsystem.
Or, though it would be less desirable from the point of view of people who have to write portable code, they could implement their own secure APIs and make the existing ones a deprecated and eventually optional add-in.
But so long as they keep the current API unchanged in all details, though, they can not solve these problems they're faced with.
OK, I missed the GUI, but even then if you ran Windowmaker or TWM it should work. You don't have to use Enlightenment or whatever insane memory hog window manager they use.
Slashdot Mirror
Can this explain Quantum Tunneling?
Can this explain Action at a Distance? (Particles separated by meters [of late] behave identically)
that's all covered in the original paper.
Can we create a situation where a quantum particle has to swap universes? That would be the killer proof
I don't believe that the EWG hypothesis allows this.
Folks have been working on reducing String Theory from 26 dimension to 11-10 (sorry, I haven't kept up). Could the high-dimensional strings be the manifestation of the "bushes"?
No, the bushes aren't in a physical dimension. "Bush" is just a way to visualize the probabilities of different states of the system.
Is it possible to send Gravity into a parallel universe around an object, thereby creating null gravity?
No. You're thinking of the wrong Greg Egan novel. We're in Quarantine, not Diaspora.
I thought this outcome was an obvious result of the original EWG model. Whether the "collapse of the wave function" is a real effect (in the Copenhagen interpretation) or a side effect of the way our measurement devices (including our senses and conscious minds) work, the uncollapsed (unobserved) state vector produces the correct results after the collapse ... there's no reason to assume that this would magically change if the collapse was "held off" indefinitely and the measurement was just performed in effect "in parallel" across multiple states.
That is, it would be headline news (well, for a certain kind of paper) if this study produced any other result.
What exactly am I missing?
Also, this doesn't "prove the multiple universe model", it just confirms that it's consistent with observation, but that's kind of the point of the model.
I couldn't disagree more - that's exactly what they're doing and will continue to do - they run almost the same software after all.
I guess we'll have to disagree on this one.
If they were trying to make them do the same job (ie, Palm-Sized PC/Pocket PC/Tablet PC... running different operating systems but all general purpose computers), then I would say so. But Apple is very clearly, it seems to me, distinguishing the iPhone/iPod from the Mac.
The iPhone is NOT "the new Mac". You seem to want to make it the new Mac, you want them to release an SDK for it, turn it into a "Pocket Mac". They don't want to do that, and have said so in no uncertain terms. They could turn that decision around, god knows they've given us whiplash of the blogosphere often enough, but right now that's NOT the course they've laid out.
The bottom line for me is that OS X is just another UNIX variant, like Linux, BSD, Solaris, or Xenix. It can be used for embedded systems or mainframes and everything in between. Using it as an embedded system doesn't signal a change in policy any more than switching to an aluminum case does.
Personally, I would love to see Apple put OS X up against Windows NT, ship a portable version for generic PCs, and ship an embedded OS X SDK for people to use in handhelds, and go so far beyond what you're looking for that it's over the event horizon. But it's not going to happen any time soon.
His complaint is that developers are locked out,
.NET so it would run on Windows and Linux, and abandon the Macintosh, if Steve didn't open up the iPhone, they may think he's really crazy and they won't listen. And if two developers, two developers do it, in harmony, they may think they're both crazy and they won't listen to either of them. And three developers do it, three, can you imagine, maybe Adobe could get involved again, they may think it's an organization. And can you, can you imagine fifty developers, I said fifty developers holding pulling up stakes because they want an iPhone SDK. And friends they may thinks it's a movement.
That's true for any appliance. You don't complain that you're locked in to your TV, or your refrigerator, or your toaster, even when they have software in them. The thing is that once you have bought a refrigerator, and you need to get a new one, you're not locked in to getting one that's compatible, that runs the same software.
The real fear here (and this is voiced in the article), is that in 10 years, when the OS X platform is mostly about mobile devices, and there are 10 million iPhones to each 1 million macs (this day will come), only Apple will control everything about these phones, and all the 3rd party developers will have to find some other platform to use, and customers will have to take what they're given, or look elsewhere.
If he means that Apple may abandon the Mac, because the iPhone and ipod are making so much money and the Mac is a liability, well, that's possible. And that's possible whether the iPhone is open or closed, and whether the iPhone is based on OS X or Windows CE. The iPhone is not a Macintosh. Just because it's running similar software, it's a different kind of device.
It's 10 years now since Microsoft started putting out Windows based handhelds. There's hardly any overlap at all between them and the Windows desktop, even though Microsoft has been trying hard to push full blown Windows NT into the handheld world. They're different kinds of devices.
All it would take from Apple would be a simple statement that the SDK is coming next year, and people should be patient till then.
You're assuming that Apple intends on there being an SDK. I don't expect so, any more. Apple is not interested in blurring the line between handhelds and desktops. After all, look how well that's worked for Microsoft.
I think Shipley rightly feels if no-one speaks out, then Jobs will think it's fine to continue down this path - perhaps even try to switch the entire OS X platform to a closed one like the iPhone, and to hell with the developers (they've said that enough times : ).
I think that Apple would have to do a lot more than introduce a new iPod (whether it's a phone or not) to make me concerned that they are headed down the path of a "sealed Mac". They may have said things like that, but when the developers dug in their heels and refused to go with Yellow Box, Rhapsody went on the shelf, Carbon came out, and OS 9, and what became OS X was delayed for years while they redesigned it to accommodate Adobe. But that's on the desktop, where they HAVE developers. Not in the handheld market, where they've already dumped them. So I don't think that ANYONE just "speaking out" is going to make Steve listen. They'd still be selling Newtons if that would work.
Now if Wil were to say that he was going to recode Delicious Monster in C# for Mono and
The main problem is - there is no device like this out there, and no prospect of one in the near future, so we have nowhere to jump ship to if Apple gets worse.
Oh, you're not worried about the Mac after all. You just want to make the iPhone into a smartphone. Well, friend, Apple has only made ONE handheld device that was open, and that was the Newton, and that was a disaster. It had potential, but it was premature... the hardware wasn't there yet... but Apple has been wary of the whole programmable handheld market since. This isn't a new thing, it's just business as usual.
I mean, just because Apple makes a product, that doesn't mean you need to get one. If the iPhone provides what you need better than the alternatives, and you don't need what it doesn't provide... go for it. If it doesn't... get something else.
There's no "platform lock-in" to the iPhone. If there was an iPhone SDK, there would be, but as it is if you don't have an iPhone you can get another phone that can still use all the same third-party content you could if you had one, and if you do you aren't locked into it. This is a different kind of lockin-in, and it's got nothing to do with developers.
On the iPod...
Now we see that iPod owners who upgrade to a newer iPod must re-buy the games they've already bought, because the new iPods are incompatible with the old. No credit given for having already bought an identical game.
Is he talking about games produced by Apple, or games produced by third parties? I don't know, I never bought games for my iPod. I never even considered buying games for my iPod. Why? Because it was obviously a closed system from the start.
But I did buy some software for my Palm, and had to re-buy some of it when I got a newer PalmOS device, because the older games didn't handle the new screen size. That's not Palm's fault, and I don't blame them for that (and not just because there's enough well-earned blame landing on them as it is).
And I'm certainly not going to *create* a platform lock-in for them by buying an iPhone and crack into it.
What should Steve do? Well, for starters, give up on trying to control everything.
Oh, I can only agree, but Steve isn't going to do that, so my recommendation is to stick to the Mac, ignore the 'appliance' products, and have an exit strategy so you can jump ship if Apple decides they're going to get serious about making the Mac an appliance again. That way we'll never have to put up with 1984 being just like 1984.
In the meantime, be picky.
Apple needs to be able to say, "Look, NBC, you want to be dumb-asses and try to sell people crap they don't want, fine -- we're still going to sell iPods that'll play your programs, we just won't sell your programs on the nicest internet store in the world. Your loss, suckers, call us when you change your mind."
I don't think Apple can say that. Because you will only be able to download those videos to your iPod on Windows: We're Sorry the requested download is unavailable. Downloads are only available to users located in the United States that have a Microsoft operating system and Internet Explorer web browser. Please check back soon for other offers.
Now *there* is your *platform* lock in.
I don't write programs for Apple because I worship Apple. I write programs for them because they have the best development environment
Don't write programs for Apple. Write programs for Macintosh. You can't write programs for Apple's appliances.
I agree with you, they should make it possible, it wouldn't even be that hard... it'd just be another target option for XCode.
But Apple's decided they're not interested in selling iAppliances to me, so I'm not going to get one.
Windows has a number of components with APIs that are impossible, even in theory, to use securely with untrusted content, and for which no alternative can be expected to be available to a Windows application. This is different from "any operating system can have a buffer overflow".
I've listed a few here and as I said in another message recently I'm absolutely appalled that people are still making up excuses for fundamental design flaws that should have been fixed a decade ago. And all these flaws are still in Vista, all the same components with the same APIs... and putting your easily exploited browser inside a leaky sandbox to "mitigate" the damage is like depending on the rhythm method to guard against AIDS. Not only is it unreliable, but if someone can compromise IE through the HTML control they don't *need* to get out of it to steal your credit card numbers and bank account passwords from a form sniffer.
Security is like sex, once you're penetrated you're ****ed.
As for the popularity argument... even in markets where Microsoft is in a minority they have still carried an inordinate percentage of the exploits. It's not because Windows is "popular", it's because Windows security is "badly designed".
* Security zones should be labelled "insecurity zones".
* No other OS *requires* a firewall simply to shut off access to essential internal services from the internet. NONE.
* Having to use the equivalent of 'system' to run applications from a browser? You gotta be kidding.
And that's just the high profile ones, the ones that have been exploited routinely. And what happens when someone finds a vulnerability? They blame the victim, arguing "yahoo instant messenger" should have "sanitized" third party HTML before passing it to the HTML control (for one recent example). Sanitized? Sanitizing a document you're passing to a turing-complete interpreter is equivalent to solving the halting problem. No, you idiots, they couldn't have "sanitized" it... Microsoft should have provided an API for calling the HTML control that didn't require "sanitization". No other bleeding HTML display engine out there defaults to granting documents full local user rights unless it guesses they're not in the "trusted zone".
HELLO, PEOPLE, LET'S HAVE SOME BLOODY SANITY HERE.
Security mechanism MUST 'fail closed'. Not 'half open' (like Vista's reduced permissions scheme) or 'full open' (like security zones).
I despair, really I do. What the HELL are people learning in college these days?
If you had read previous followups you wouldn't need to ask.
What's more disturbing to me is that these flaws have been around for so long and people are still making excuses for them.
The iPhone has a huge margin with or without the price drop. Only taking 30% margin instead of 50% (or whatever the figures are, they're around that order of magnitude) isn't "fire sale" pricing.
Not quite... shaders are used for faking surface properties that you don't want to do with actual geometry.
Yep, and you may still want to do that with raytracing... polygons are cheaper for a raytracer, but they're not free. The biggest bottleneck for raytracing is memory bandwidth, and it's still possible to choke it with polygons. It's not a magic wand.
I think there have been some CG productions that have rendered hair as individual strands.
Yes, it's possible, but they don't have to do it in realtime.
1. Outlook doesn't use the standard HTML control for rendering, it uses a separate control from Microsoft Word. Perhaps even Microsoft has realized the standard Microsoft HTML control is inherently insecure, but that doesn't help anyone else, because it's the only one that's universally available in all Windows systems, and it's the one Microsoft themselves use for everything else.
... you don't have to be running a server to have your ass hanging out, and none of these services are designed to run bound to localhost only.
2. Parsing command-line application arguments is a huge hole. Users don't use the command line much, but programs call other programs that way all the time. There have been at least two exploits I know of in the past few months taking advantage of command line parsing.
3. You don't need a firewall at all on any modern BSD- or Linux-based system unless you run public services. Some systems come with services on by default, but there's plenty of "secure as shipped" systems available. If there's no service listening at a port, there's no way to attack through that port. If all TCP based services required locally only listen to localhost, there's nothing exposed for a firewall to protect. And on top of that Windows opens up all kinds of ports: the old Lan Manager ports, SMS, Messenger service,
Shaders are used for defining surface properties. I don't think vertex shaders at least would completely go away.
Do you see an efficient way to do things like hair in a real-time raytraced scene without some kind of program in the GPU? Converting the hair to polygons would be insane.
did you just make that up to sound smart?
No, I've been sounding the alarm for a decade now. I've yet to see any evidence that Microsoft has made any serious attempt at fixing the fundamental design flaws that were already making it the prime target for malicious software in 1997.
win32 has been deprecated and sandboxed out for compat
If it was sandboxed it would be completely safe to download and run a hostile Win32 application under Vista, with no chance of damage to your OS, local content, etcetera. A sandbox that doesn't actually prevent access outside the sandbox is no sandbox at all. A sandbox that has everything that actually matters to the user inside it is no sandbox at all.
Win32 remains the basic Windows API in Vista. Until Microsoft fixes the APIs that already exist, and accepts the pushback from developers and users as a necessary cost of security, all they're doing is applying bandaids.
Three fundamentally insecure windows APIs:
The HTML control: Having the HTML control provide a mechanism to execute code in a document with local user permissions at all is unacceptable. Given that exists, the "security zones" mechanism to control access to it fails "open", not "closed".
Program execution: The application being called is responsible for parsing the command line into components. Microsoft themselves have admitted it is impossible for an application to completely sanitize a command line in the general case, even where the command line is specified by an API.
Network servers: There is no general mechanism to control the binding of services to specific interfaces, which forces you to use firewalls, which would otherwise be a second layer of defense, to become the only way to prevent external access to internal services using TCP.
The fundamental security flaws in the APIs that Windows has been burdened with are still there. They're not going to go away, if Microsoft is still keeping them there after 10 years of vigorous exploitation. Adding more "mitigating factors" to try and reduce the danger once your system is penetrated through one of them is useful, yes, but the bottom line is still the same... security is like sex... once you're penetrated you're ****ed.
First, these licenses don't look bad to me. I really need more information about what the OSI's objections are.
Second... having an open source license isn't anything like the whole of the story. In fact, open source itself is only half the story.
Open Systems is at least as important as open source. Open systems means interfaces, APIs, protocols, and soon designed for interoperability, openly documented, and not under any single vendor's control. Samba is open source, but it's not implementing an open systems protocol because Jeremy Allison pretty much has to implement whatever Microsoft does. Heck, GCC has gone through periods where it was as proprietary as any Microsoft product, with all kinds of custom extensions that provided a barrier to entry for anyone who wasn't GCC or wasn't using GCC.
Microsoft's track record with open systems has been pretty bloody bad since long before the GPL was drafted.
When they started getting gung-ho about POSIX, that looked like a major turnaround, but the result was a POSIX implementation that was deliberately useless. They embraced open systems just enough to get NT into government purchases, and throttled it.
So let's see what they do *with* these licenses, before we get excited.
There would need to be some level of OpenGL emulation, I would think.
:) I suspect that if you can get data in there fast enough you could blow past a billion rays a second without even trying, since raytracing performance scales up pretty much linearly with the number of processors.
Let's think about what "good results" would mean, using the level of investment currently applied to rasterization.
The SaarCOR design gets 7-8M rays per second with an FPGA with 6M programmable gates. A good GPU may have 600M transistors... with things like multi-gate transistors I don't know exactly how you'd compare them, but let's be conservative and assume it's 1:1... so with 100 times the component budget, and maybe 8-10 times the clock speed, you should be able to implement a heck of a raytracer in hardware if you're nVidia or ATI. Or, for that matter, Intel... who has (one must admit) pretty damn good processor technology.
Without the ability to build native applications for it, it's not even on my radar.
The kind of hardware needed to run raytracing really fast is well understood, and it doesn't really look like today's GPUs or like intel's CPUs, though even today you can get better results if you take advantage of the GPU as well. If ATI or nVidia doesn't come up with a hardware raytracing GPU someone else will. It's a pity that Intel doesn't seem to be interested in working on that angle.
Here's an article I've dug out of the Wayback machine and cleaned up, Raytracing vs Rasterization. Phillip Slusallek's home page is here, and you can follow that to SaarCOR and OpenRT. They built a prototype RPU (R for raytracing) that at 66 MHz was comparable in performance to a 2.6 GHz P4. The video is pretty impressive, considering how slow the hardware is.
One of the benefits of raytracing is that it can render real curved surfaces, including NURBS and volumetric surfaces: without taking advantage of this aspect of the technology, would we really see much visual benefit?
Sure. Even without the obvious things you're pooh-poohing like reflection and refraction (and raytracing can produce good results for these on curved surfaces), you get universal shadowing (including self-shadowing, the lack of which really stands out for me in even the best rasterized images), far better shading and bump-mapping, and better illumination... and reduced development costs because so many things that are handcrafted now fall out of the technology.
Look at the second image. Look at the guy in the background. Look how his body beneath the gun is shadowed. You're never going to get that kind of effect from rasterizing. And that makes things look a lot more "plasticky" to me than sharp edged shadows do.
Open source licenses need to be compatible with other licenses to get approved now?
In general, incompatibility with other open source licenses is considered a bad thing, yes. If they are in fact "maximally incompatible" I would say that's a problem. On the other hand, I would like to see what they specifically claim are incompatibilities. I'm not sure that I see any showstoppers.
As long as it is possible for the WM to ignore the app (e.g., in cases where the user has set specific settings for that app in the WM configurations), then I don't see any reason why window managers shouldn't be able to support that.
Um, that's pretty much a paraphrase of what I've been saying. That the protocol needs to extended to allow windows to be declared specifically as the kind of tightly dependent windows I'm talking about. Because right now there doesn't seem to be a way to say that... simply making them child windows doesn't carry the same implications or there wouldn't be any perceived need for applications to override the WM.
Yes, because EVERY widely-used OS must be a Unix variant
.NET and I'm concerned with the possibility of them resurfacing in Mono and Moonlight.
I didn't say "best", I said "easiest". As I noted, they already have the code implemented and working in NT, in the POSIX subsystem.
Also, "becoming a UNIX based system" doesn't mean becoming a UNIX variant. There's nothing fundamentally wrong with the NT kernel on the desktop and (again) as I noted they have the code, they could expose as much or as little of it as they needed.
In addition, I didn't say "must". The very next paragraph presented the alternative of creating a new API that avoided the problems of the current ones but still worked for traditional command line programs, and deprecating the use of the current API for launching programs. While it would be best for people who write portable code if this was based on the UNIX "exec" call, that's certainly not a requirement.
did you notice that NONE of the problems you talked about have anything at all to do with whether an OS is built on top of Unix or NT or whatever?
Actually they do.
First, when launching a command line program under Windows the parameters are parsed into options and file names by the called program, not the calling program. In UNIX, this operation is performed by the calling program, so it can unambiguously pass strings containing quotes and other metacharacters to the called program without having to guess how they will be broken up into words. There have been a steady stream of exploits that take advantage of this design flaw.
Secondly, program in UNIX universally inherit a lot of context from the parent, including open file descriptors. This allows a network superserver (like inetd on UNIX) to manage the connections for network services without having to have each application independently provide their own API and configuration tools to control the ports they listen to. This is not part of the NT API... first, because open files and sockets are not the same kinds of objects, and second, because the process hierarchy in NT is convention rather than something built in to the system.
Both of these problems would be solved by deprecating CMD.EXE and the old DOS-derived Windows command line API, and the split between sockets and files that's the heritage of the old Lachman Winsock library, and going to a UNIX API for files and processes. Obviously there are other ways to do the same thing, but unless Microsoft actually implements one and takes steps to convert everything over to one that's kind of academic.
Now this isn't the same thing as having the OS "built on top of UNIX", but that's not what I said. There are many UNIX-based operating systems that are built on quite different kernels and with quite different underlying designs... some which are proud of their membership UNIX family while clearly being a different kind of OS, like QNX and BeOS, and others that keep their UNIX roots at arms length and the APIs partitioned off in a separate subsystem, like Windows NT. Windows already has an enormous amount of such indirect inheritence from UNIX thanks to Microsoft's aborted plan to merge MS-DOS and Xenix (this started with MS-DOS version 2). Which is precisely WHY this would be "the easiest solution".
Not the only. Maybe not even the best. But certainly the easiest.
The third of the main points I brought up - the HTML control - wouldn't automatically be solved by this design, but this comment was addressing the second half of my message (starting with "There are other problems, too.") Obviously the flaws in the HTML control could be cloned in UNIX. Apple has managed to copy one of them, unfortunately, and some have been carried forward into the design of
I actually DO agree that having zero security holes in any software as large as Windows (or Linux) is an unrealistic goal.
That's not what they're being asked for. What they're being asked for is for systematic holes to be eliminated, so they don't have to keep being patched over and over again. I've listed some of the systematic holes in the design that they keep getting bit by in the message I posted just before yours.
The thing that really bothers me is that people are accepting the argument that holes Microsoft created are not Microsoft's fault. People are blaming applications that didn't sanitize untrusted content before passing it to insecure APIs, rather than blaming Microsoft for not providing a secure API they could use instead.
The biggest problem is, of course, the HTML control.
Until Microsoft abandons the entire "security zone" model and makes the HTML control default to a secure or "closed" state completely under the management of the calling application Windows security will never be anything but a joke. The recent hole in Yahoo Instant Messenger, for example, is primarily Microsoft's fault... because the "security zones" should not be able to "fail open". Blaming Yahoo for not 'sanitizing' the input is nuts.
No other HTML rendering library works this way. The two leading alternatives... Mozilla's Gecko and KDE's KHTML (and thus Apple's Webcore)... both implement a closed sandbox. If an application wants the page to have more capability, it must explicitly install hooks to grant it that capability. This way when an application renders a page using Gecko or KHTML there's no possibility of there being prepared holes to attack. In addition, when they DO install a controlled hole in the sandbox, they know that they're the only agency doing so... there's no concerns about some insecure ActiveX control in the system becoming an avenue of attack.
Until Microsoft completely changes the API for the HTML control they won't solve their image problem, and they shouldn't expect to... because until they do this, they have a problem and the image only reflects that.
ActiveX use in the HTML control, of course, is completely insane. Given all the layers of bandaids and patches and dialogs and settings and security levels wrapped around them, it's actually less effort to explicitly install a plugin than to open IE up to the point where you can use a "trusted" ActiveX control. They need to deprecate and eventually eliminate this.
There are other problems, too. Applications have to parse command lines completely, using their own code to break them up into arguments and perform wildcard expansion. Both OS X and Linux use the UNIX "exec" call, which doesn't require the application to add this additional evaluation step. Many of the "URI" related holes found in applications on Windows... including several recent ones involving IE, Firefox, and Second Life... are due to this flaw in Microsoft's APIs.
There's a second flaw in their URI handlers, and that is the inability to separate internal handlers that may expose more powerful capabilities than a sandboxed object should have access to with the ones that are designed for use by untrusted documents. The 'patch' to fix this is to try and sanitise the list of URI handlers that each application will use. This, like any other "sanitization-based" approach, is inherently flawed. They need to create a second registry that only supposedly secure applications will use... and then they won't need to worry about web pages containing links to ".CHM" files.
(Apple, by the way, has copied this flaw from Microsoft. But at least they don't share the rest of the burden)
The lack of a standard mechanism to bind network services to specific interfaces is a third problem. In UNIX most network services have traditionally been run from inetd, so if you replace inetd with something like xinetd or tcp wrappers you can prevent services from listening to anything but the local interface "localhost". This means that a firewall on UNIX is an extra defense, where on Windows it's the only way to keep insecure protocols from accepting connections from external sources.
For Microsoft to get the same reputation for security that UNIX based systems have earned, it will have to correct these flaws. The easiest way, perhaps, would be for it to BECOME a UNIX-based system. It wouldn't take much, so much of the API is already inherited from Microsoft's one-time infatuation with UNIX, and they ship a subset of teh UNIX API with Windows in the POSIX subsystem.
Or, though it would be less desirable from the point of view of people who have to write portable code, they could implement their own secure APIs and make the existing ones a deprecated and eventually optional add-in.
But so long as they keep the current API unchanged in all details, though, they can not solve these problems they're faced with.
OK, I missed the GUI, but even then if you ran Windowmaker or TWM it should work. You don't have to use Enlightenment or whatever insane memory hog window manager they use.