Yes, I know they can stop them at the political/financial layer (or at least play cat-and-mouse games with people who sneak "accidental" backdoors in anyway). What I want to know is if they have built any technical restrictions into the API... for example, running installed apps as non-root in a chrooted or jailed environment, or restricting the system calls available to installed apps.
They control the OS, so they can kill -9 anything they please at any time they like.
That's got nothing to do with them controlling the OS... any application can do the same thing. They all run as root.
But, yes, I agree, they could have some daemon sitting there looking for unexpected processes and killing them, but if they did wouldn't you expect it to have shown up by now?
This isn't anything to do with saving face on a lost cause, it's saving money on movies that you can buy right now. Don't forget, that HD player will still play regular DVDs, so for someone who doesn't have those "GOTTA GET SOME OF THAT" early adopter genes, a choice of 500 cheap titles for a $75 player is a better deal than 700 full price titles for a $320 player.
Apple has every right to lock in the iPhone, yes, but that doesn't mean we have to go along with them.
As for Silverlight... no thanks. Microsoft has proven that their 'no sandbox' security model is completely unworkable so many times that it amazes me that anyone would consider taking yet another spin on the wheel. ActiveX,.NET, Silverlight, Moonlight, it's all the same vigorous viral ecosystem.
I've seen a lot of speculation about the iPhone being somehow insecure, but most of the "security issues" I've seen have been from companies who want to sell security software, or that want to lock down company owned phones. The former can be dismissed as sales material, and the latter are at BEST irrelevant to most users.
Unless you're talking about jailbreak? That's not a security hole, that's an advantage. I wish I could jailbreak my own cellphone, since Sprint has locked out most of the functionality that led me to pick the model I did.
After watching Microsoft stumble around trying to make unsandboxed execution of untrusted code work for over a decade, and failing, I think it's pretty clear that this is an unsound model, whether it's called ActiveX,.NET, Silverlight, or Moonlight.
One of the reasons I try and limit myself to what I can take in a carry-on is to avoid having my bags subjected to the gentle ministrations of the baggage handlers. Thump, thump, thump...
You want to subject your laptop to that?
If people are worried about their items (let's face it, stuff "disappears"), video tape it from start to finish and let people inspect the tape.
Let's have them do that for checked baggage first so we can see how well it works.
Raytracing avoids aliasing effects within an object, but without oversampling (say, shooting multiple rays near the corners of pixels that are near the edge of an object) you get just as much aliasing at edges. The folks at SaarCOR have demoed some interesting edge detection algorithms that allow them to only do supersampling where it's needed.
"A related effect is called ambient occlusion. An example of ambient occlusion is in the corner of a room, where the points on the surface of the wall near the corner can't "see" very much of the room, so those points are not as well-lit as points in the center of the wall."
I'm not sure what optical effect he's referring to. Ambient light is an approximation for second and higher order reflections, and depending on the brightness of the adjacent surfaces corners of a room may or may not seem darker than the surrounding wall. With interior lighting, the fact that they are simply further away from the light source is going to have a bigger impact (if you're in a room that's not lit by ceiling panels you can look at the ceiling of the room you're in too see what I mean). In addition, in the room I'm in, an even bigger factor is the wall texture - it's slightly glossy and the diffuse reflection of the overhead light is far more apparent than the slightly darker secondary reflections in the corner.
Following up on my previous post about the debate between David Kirk and Philipp Slusallek in 2006 (link... apologies to Dr. Slusallek, Slashdot truncated his name).
According to Dr. Slusallek's LinkedIn profile he's currently a "Visiting Professor at NVIDIA".
The performance of Dr. Slusallek's real-time raytracing engine at only 90 MHz was quite impressive: "In contrast we have recently implemented a prototype of a custom ray tracing based graphics card using a single Xilinx FPGA chip. The first results show that this really simple hardware running at 90 MHz and containing only a small fraction of the floating point units of a rasterization chip already performs like a 8-12 GHz Pentium 4. In addition, it uses only a tiny fraction of the external memory bandwidth of a rasterization chip (often as low as 100-200 MB/s) and therefore can be scaled simply by using many parallel ray tracing pipelines both on-chip and/or via multiple chips.".
It seems there may be room for more than one opinion about the future of raytracing and gaming at nVidia.
There used to be an interesting debate between Professer Philipp Slusallek of the University of Saarbruecken and chief scientist David Kirk of nVidia at GameStar.de. The original article has been taken down, but I found a slightly mangled version on the Wayback machine and I've cleaned it up a bit and put it up on my not-a-blog: link.
I'd appreciate a better translation of the German part of the text.
Uh, read the thread and you'll understand: you get one task, and it terminates.
Where does it say that, I've been groveling through the thread for way too long and I can't find anything other than a somewhat confused paragraph by "postbigbang" that I can't make head nor tail of:
With current OSX frameworks, it's now time to disable lots of stuff you've come to enjoy. READ the docs. Please throw out your multitasking and other delicious inter-app communications frameworks; get lots of your information from your newly rebuilt parsers. Do the type-checking carefully, lest you blow up your app, and others, too. That's because it's a serial machine, not a concurrency machine. That means that object types have to be built carefully to thread linearly and consecutively while you have the machine, because it's single-task and other events will cause havoc-- and they're not in your control as the kernel decides 'who's-on-first'.
It's UNIX, it's got fork() and exec(), what more do you need?
But perhaps his best argument is this one: "Definitions of business method patents always end up being circular," he said. "You can't really ban something unless you can define it and no one is offering a definition we can use."
This seems to be a bit of a straw man. A decision in this case is unlikely to be "business method patents are banned", but rather a limitation of the kinds of claims that are protected. This will be unlikely to do anything so simple as banning business method patents or algorithm patents, but rather make it harder to get and defend patents that depend on those kinds of claims.
This sounds like it's something to keep Random East Asian Fab from running off a few million extra licensed chips and selling them on the grey market... not something to lock out the end user if he doesn't pay the annual fee. The upside is that you'll never even know when you're buying something protected by EPIC. The downside is that you'll never know until EPIC FAILs. And maybe not even then.
Slashdot Mirror
Yes, I know they can stop them at the political/financial layer (or at least play cat-and-mouse games with people who sneak "accidental" backdoors in anyway). What I want to know is if they have built any technical restrictions into the API... for example, running installed apps as non-root in a chrooted or jailed environment, or restricting the system calls available to installed apps.
They control the OS, so they can kill -9 anything they please at any time they like.
That's got nothing to do with them controlling the OS... any application can do the same thing. They all run as root.
But, yes, I agree, they could have some daemon sitting there looking for unexpected processes and killing them, but if they did wouldn't you expect it to have shown up by now?
This isn't anything to do with saving face on a lost cause, it's saving money on movies that you can buy right now. Don't forget, that HD player will still play regular DVDs, so for someone who doesn't have those "GOTTA GET SOME OF THAT" early adopter genes, a choice of 500 cheap titles for a $75 player is a better deal than 700 full price titles for a $320 player.
How can they prevent third-party applications from running in the background?
Your original comment implied that it was already "insecure": wont this make the iphone even more insecure than it already is.
Do you know something more than I've been able to pull up, or were you talking through your hat?
Apple has every right to lock in the iPhone, yes, but that doesn't mean we have to go along with them.
.NET, Silverlight, Moonlight, it's all the same vigorous viral ecosystem.
As for Silverlight... no thanks. Microsoft has proven that their 'no sandbox' security model is completely unworkable so many times that it amazes me that anyone would consider taking yet another spin on the wheel. ActiveX,
Having the menu system change whenever you focused on a different window in the same app would not be very mac-like.
They could merge the menus and disable the entries that aren't associated with the active window, just like any other app.
If Apple hasn't been proactive in trying to port Java to the iPhone I expect they must have a good reason
Control.
Apple wants to control application access to the iPhone.
I've never been a huge fan of the iPhone, and Apple's continual foot-dragging over opening it up is getting increasingly old.
I've seen a lot of speculation about the iPhone being somehow insecure, but most of the "security issues" I've seen have been from companies who want to sell security software, or that want to lock down company owned phones. The former can be dismissed as sales material, and the latter are at BEST irrelevant to most users.
Unless you're talking about jailbreak? That's not a security hole, that's an advantage. I wish I could jailbreak my own cellphone, since Sprint has locked out most of the functionality that led me to pick the model I did.
After watching Microsoft stumble around trying to make unsandboxed execution of untrusted code work for over a decade, and failing, I think it's pretty clear that this is an unsound model, whether it's called ActiveX, .NET, Silverlight, or Moonlight.
One of the reasons I try and limit myself to what I can take in a carry-on is to avoid having my bags subjected to the gentle ministrations of the baggage handlers. Thump, thump, thump...
You want to subject your laptop to that?
If people are worried about their items (let's face it, stuff "disappears"), video tape it from start to finish and let people inspect the tape.
Let's have them do that for checked baggage first so we can see how well it works.
Raytracing avoids aliasing effects within an object, but without oversampling (say, shooting multiple rays near the corners of pixels that are near the edge of an object) you get just as much aliasing at edges. The folks at SaarCOR have demoed some interesting edge detection algorithms that allow them to only do supersampling where it's needed.
"A related effect is called ambient occlusion. An example of ambient occlusion is in the corner of a room, where the points on the surface of the wall near the corner can't "see" very much of the room, so those points are not as well-lit as points in the center of the wall."
I'm not sure what optical effect he's referring to. Ambient light is an approximation for second and higher order reflections, and depending on the brightness of the adjacent surfaces corners of a room may or may not seem darker than the surrounding wall. With interior lighting, the fact that they are simply further away from the light source is going to have a bigger impact (if you're in a room that's not lit by ceiling panels you can look at the ceiling of the room you're in too see what I mean). In addition, in the room I'm in, an even bigger factor is the wall texture - it's slightly glossy and the diffuse reflection of the overhead light is far more apparent than the slightly darker secondary reflections in the corner.
Following up on my previous post about the debate between David Kirk and Philipp Slusallek in 2006 (link ... apologies to Dr. Slusallek, Slashdot truncated his name).
According to Dr. Slusallek's LinkedIn profile he's currently a "Visiting Professor at NVIDIA".
The performance of Dr. Slusallek's real-time raytracing engine at only 90 MHz was quite impressive: "In contrast we have recently implemented a prototype of a custom ray tracing based graphics card using a single Xilinx FPGA chip. The first results show that this really simple hardware running at 90 MHz and containing only a small fraction of the floating point units of a rasterization chip already performs like a 8-12 GHz Pentium 4. In addition, it uses only a tiny fraction of the external memory bandwidth of a rasterization chip (often as low as 100-200 MB/s) and therefore can be scaled simply by using many parallel ray tracing pipelines both on-chip and/or via multiple chips.".
It seems there may be room for more than one opinion about the future of raytracing and gaming at nVidia.
There used to be an interesting debate between Professer Philipp Slusallek of the University of Saarbruecken and chief scientist David Kirk of nVidia at GameStar.de. The original article has been taken down, but I found a slightly mangled version on the Wayback machine and I've cleaned it up a bit and put it up on my not-a-blog: link.
I'd appreciate a better translation of the German part of the text.
When we finally get people to agree what RAID-6, 7, 8, and 10 are.
Hey, looks like nobody's invented RAID-9 yet. MARKET OPPORTUNITY!
There are 10.0 kinds of web users, those who understand binary and those who are tired of this joke.
Yah, I would be surprised if even 5% of the users made *any* edits.
And 1% of Wikipedia users is still a huge number of people.
Where does it say that, I've been groveling through the thread for way too long and I can't find anything other than a somewhat confused paragraph by "postbigbang" that I can't make head nor tail of:
It's UNIX, it's got fork() and exec(), what more do you need?
non-multi-tasking
It's running UNIX. What more multi-tasking do you need?
Now you want it to be completely open so you are free to hack away at it even though no company could support such a device?
Palm and Microsoft seem to be able to manage it. What planet do you live on where there are no smartphones?
Go make your own 4G, super VoiP, free Radio, Open Source phone that does everything the iPhone doesn't.
They don't seem to have Google on your planet either.
He already demoed instant erase of the iPhone.
This seems to be a bit of a straw man. A decision in this case is unlikely to be "business method patents are banned", but rather a limitation of the kinds of claims that are protected. This will be unlikely to do anything so simple as banning business method patents or algorithm patents, but rather make it harder to get and defend patents that depend on those kinds of claims.
This sounds like it's something to keep Random East Asian Fab from running off a few million extra licensed chips and selling them on the grey market... not something to lock out the end user if he doesn't pay the annual fee. The upside is that you'll never even know when you're buying something protected by EPIC. The downside is that you'll never know until EPIC FAILs. And maybe not even then.
If I can download the SDK, the SSH.app source code, compile it, and then upload it via the SDK, that'd be perfect.
It sounds like that will be a valid option, yes... unless they expect you to do all your app development in their iPhone emulator under OS X.