Self-contained applications is a nice idea, but it makes sense primarily with non-free binary only applications which the user or the OS distribution can't build from source code. If you use a system like Debian stable then you will rarely have any problems with the package manager, and as long as you're using software which is distributed as part of Debian you can be assured that a maintainer has looked at it, that it is licensed under a DFSG compatible license and will most likely not harm you.
You don't have the same thing on OS X and especially if you're running non-free programs downloaded from the net. That's why Apple is pushing so hard for sandboxing applications, since the user is ultimately unable to trust many of the applications.
I think the idea is that you don't do that. Each application is supposed to use the system software as far as possible, and if an application vendor ships a third party library as part of their application bundle then that vendor is supposed to maintain it when needed. Won't be perfect from a storage efficiency point-of-view but each application will be more or less independent.
The general stance is that it's not optimal bus also not a critical problem since it's not part of the OS and only used to enable certain hardware. There's no plan to remove them as far as I know, although there is work going on in tweaking the build system so that you can build a FreeBSD distribution where they are omitted.
* The OS and the applications are separate. This means that you can have up to date versions of your desktop and all applications on a stable core OS. On Debian you would either have to build things yourself or upgrade your entire system to testing or sid. * A mature ZFS implementation. You can use ZFS-on-Linux or Btrfs for similar functionality on Debian, but it's often not considered to be as production ready as ZFS on FreeBSD. Also for license compatiblity issues ZFS-on-Linux will never ship as part of a GNU/Linux distribution and will have to be installed separately.
Disadvantages:
* Not as good hardware support. Usually works well on desktops and servers, but it can take some tweaking to get it to work well on modern laptops. * Some software does not run on FreeBSD. Very uncommon for open source, but can be a problem if you're running non-free software. You can mitigate this by installing the Linux compatibility layer on FreeBSD.
OSX = BSD, so yeah, its been year of BSD on the desktop for about a decade.
It includes part of the FreeBSD userland. I don't know if I agree that it makes it BSD. The FSF would probably agree though since they insist that Linux + the GNU userland should be called GNU/Linux, so they would probably argue that it should be called BSD/OS X if they were interested.
If there are actually are warning signs, and I can hardly find playing a shoot-em up game to be a warning sign, then you send them to psychiatrists and have them look at it. You don't arrest them and have them face criminal charges.
look at it from the police perspective. What if they do nothing. What if next year this kid really does do something? Who do you think will get the blame? The police will. So, they act, even though they know it is complete nonsense. Because they know that if this kid does anything down the line, they will be a scape goat for ignoring the obvious "warning signs". Crap I know, but that is how it could go down.
They should arrest him if he actually does something illegal. You don't arrest people because of "warning signs."
What you are descibing is essentially regular drivers. It's exactly the same thing that regular computer operating systems uses. The camera is not in any way built for Windows, it just happens that it require a driver and that driver is available for Windows Phone. With the appropriate driver the same camera should work in any operating system.
I recently installed XP x64 SP2 on a new machine for compatibility testing. But the update process is embarrasing compared to Debian. I wonder how it can take so much time to apply each update.
When someone says that something is an "Android Phone" or a "Windows Phone" or an "iOS Phone" then all they say is that it's a general purpose computer that has been locked down to running that particular OS. There's no technical barrier in installing Android on a "Windows Phone", just like there's nothing stopping you from installing Debian GNU/Linux on a "Windows Computer."
I forget how many cat versions Apple used to say was finally ready for 64 bit. I think it started in 10.2, 10.3 definitly had it. But Cocoa didn't go 64 bit until 10.5 and the kernel was still 32 bit until 10.7. So I don't know about this "designed from the ground up", more like "bolted on in the last minute."
If it's such a big deal in order to get the same software to run on both systems then how does the Debian project manage to bring 37 000 packages to all eight architectures that it's currently running on? Magic?
Slashdot Mirror
Because no one else would. Maybe not always the best thing, but often a lesser bad thing than to stay aside and watch.
It could be that it's based on PowerVR.
I have not killed people, yet I think it is immoral.
I have not owned a patent, yet I think it is immoral.
No. I just find that the concept of patents is trolling the human mind, so everything that involves patents is trolling.
I would go without the "if you didn't create it." I've yet to find a single patent case that wasn't trolling.
It is very common with press releases.
That's what you have backups for.
Sounds like the right way to solve the problem.
Maybe I'm missing out here but I'm pretty sure a PowerPC Mach-O or PEF binary for Mac OS X from 2001 won't run on a modern system.
Self-contained applications is a nice idea, but it makes sense primarily with non-free binary only applications which the user or the OS distribution can't build from source code. If you use a system like Debian stable then you will rarely have any problems with the package manager, and as long as you're using software which is distributed as part of Debian you can be assured that a maintainer has looked at it, that it is licensed under a DFSG compatible license and will most likely not harm you.
You don't have the same thing on OS X and especially if you're running non-free programs downloaded from the net. That's why Apple is pushing so hard for sandboxing applications, since the user is ultimately unable to trust many of the applications.
I think the idea is that you don't do that. Each application is supposed to use the system software as far as possible, and if an application vendor ships a third party library as part of their application bundle then that vendor is supposed to maintain it when needed. Won't be perfect from a storage efficiency point-of-view but each application will be more or less independent.
The general stance is that it's not optimal bus also not a critical problem since it's not part of the OS and only used to enable certain hardware. There's no plan to remove them as far as I know, although there is work going on in tweaking the build system so that you can build a FreeBSD distribution where they are omitted.
Advantages:
* The OS and the applications are separate. This means that you can have up to date versions of your desktop and all applications on a stable core OS. On Debian you would either have to build things yourself or upgrade your entire system to testing or sid.
* A mature ZFS implementation. You can use ZFS-on-Linux or Btrfs for similar functionality on Debian, but it's often not considered to be as production ready as ZFS on FreeBSD. Also for license compatiblity issues ZFS-on-Linux will never ship as part of a GNU/Linux distribution and will have to be installed separately.
Disadvantages:
* Not as good hardware support. Usually works well on desktops and servers, but it can take some tweaking to get it to work well on modern laptops.
* Some software does not run on FreeBSD. Very uncommon for open source, but can be a problem if you're running non-free software. You can mitigate this by installing the Linux compatibility layer on FreeBSD.
OSX = BSD, so yeah, its been year of BSD on the desktop for about a decade.
It includes part of the FreeBSD userland. I don't know if I agree that it makes it BSD. The FSF would probably agree though since they insist that Linux + the GNU userland should be called GNU/Linux, so they would probably argue that it should be called BSD/OS X if they were interested.
If there are actually are warning signs, and I can hardly find playing a shoot-em up game to be a warning sign, then you send them to psychiatrists and have them look at it. You don't arrest them and have them face criminal charges.
They didn't investigate. They arrested him and he's now facing criminal charges.
look at it from the police perspective. What if they do nothing. What if next year this kid really does do something? Who do you think will get the blame? The police will. So, they act, even though they know it is complete nonsense. Because they know that if this kid does anything down the line, they will be a scape goat for ignoring the obvious "warning signs".
Crap I know, but that is how it could go down.
They should arrest him if he actually does something illegal. You don't arrest people because of "warning signs."
Except there was no incident. No one was harmed and there was no intention to harm. He was playing an augmented reality game, that was all.
No you don't. You should use your brain first.
What you are descibing is essentially regular drivers. It's exactly the same thing that regular computer operating systems uses. The camera is not in any way built for Windows, it just happens that it require a driver and that driver is available for Windows Phone. With the appropriate driver the same camera should work in any operating system.
I recently installed XP x64 SP2 on a new machine for compatibility testing. But the update process is embarrasing compared to Debian. I wonder how it can take so much time to apply each update.
When someone says that something is an "Android Phone" or a "Windows Phone" or an "iOS Phone" then all they say is that it's a general purpose computer that has been locked down to running that particular OS. There's no technical barrier in installing Android on a "Windows Phone", just like there's nothing stopping you from installing Debian GNU/Linux on a "Windows Computer."
I forget how many cat versions Apple used to say was finally ready for 64 bit. I think it started in 10.2, 10.3 definitly had it. But Cocoa didn't go 64 bit until 10.5 and the kernel was still 32 bit until 10.7. So I don't know about this "designed from the ground up", more like "bolted on in the last minute."
If it's such a big deal in order to get the same software to run on both systems then how does the Debian project manage to bring 37 000 packages to all eight architectures that it's currently running on? Magic?
You can't be held responsible for something that was done in top secret without you knowing about it.