If that was the case, MS is dreaming. Google can turn their access off at a whim (problem solved), and MS would need to go to court and most definitely lose to try and force google to re-enable access to a free service that explicitly prohibits their behavior in the sites terms of service.
You agree not to alter or modify any part of the Service.
Section 4j
YouTube reserves the right to discontinue any aspect of the Service at any time.
Section 5b
Content is provided to you AS IS. You may access Content for your information and personal use solely as intended through the provided functionality of the Service and as permitted under these Terms of Service. You shall not download any Content unless you see a “download” or similar link displayed by YouTube on the Service for that Content. You shall not copy, reproduce, make available online or electronically transmit, publish, adapt, distribute, transmit, broadcast, display, sell, license, or otherwise exploit any Content for any other purposes without the prior written consent of YouTube or the respective licensors of the Content. YouTube and its licensors reserve all rights not expressly granted in and to the Service and the Content.
I'm sure there are also other sections that could be used as justification by youtube to block MS user's access to the content without any problem at all.
Depends on how you quanity "better product". The only android device i've yet seen which even slightly interests me is the HTC one, due to its construction. It doesn't matter what the spec of a phone is or what it can do - if it feels like a turd to use, the experience is not going to be pleasant. Look up "haptics".
Pretty much. I'm sure it must be in google's terms of service somewhere that they "reserve the right to terminate service at any time for any reason", etc.
Except it isn't the same software stack down to the operating system. The one thing all of these exploits have in common is they are running on Linux. What's to say there isn't a flaw in the kernel somewhere that is exposed via these web servers?
Ubuntu does not have the same feature set as Windows 7. I was comparing a modern Linux distribution to Windows XP because the feature set is comparable. Release date doesn't really matter a shit, it's what you can actually DO with the operating system that is relevant.
Funny. I had XP running on 32MB when it came out. It wasn't blisteringly fast, but it was enough to burn CDs and stuff. It performed better with 32 MB than Windows 95 did with 4 MB which was the official requirement on release.
Uhh... typical mac installer. Fuck package mangers.... want to move the app to a different disk? Drag/drop. No dependency bullshit to deal with. Can run it from the network if i really wanted to.
As opposed to the status quo, where if a fundamental library is replaced, it may cause breakage in every dependent app, resulting in a substantial burden.
Mac OS has been using application bundles since forever, and seems to manage just fine.
RAM and DISK became far, far cheaper than the time spent dealing with dependency bullshit incurred when you try to do something but can't because the feature is not included in the base OS.
So, why does Linux now need 256 MB of RAM pretty much as a minimum, to give a similar desktop experience to Windows XP which used to run in 2002 on 32 MB?
Having lived with this approach on OS X for 3 years now, I am all for it. Install/uninstall for the vast majority of stuff is very basic drag/drop. Maybe clean up some saved preference plist files if you care about not having the configuration come back if you ever reinstall the app. I have not noticed any massive shortage of disk space. Most of an application's code is not shared, anyhow.
I suspect the memory/CPU overhead for dedup is far larger than the disk/memory overhead for self-contained applications. Disk is cheap. RAM is cheap. Most of the application will be its OWN CODE, anyhow.
Yes. ZFS will do this, as will HAMMER. However, I suspect the gains REALLY aren't there. The core OS binaries (including all libraries) on a modern system account for what... 1-2% of the disk space? If that? The bulk of the code in your new application will be the new application. Even more disk will be consumed by the resources used only for that app (graphics, widget layouts, etc.).
Disk today is cheap. Having dealt with both linking (Windows, Unix) and self contained Applications (OS X), I much prefer the latter. Installation / un-installation is way, way easier. Compatibility issues are less common.
Which, given most people have upwards of half a terabyte of storage, and the OS consumes only 1% of that, storage space is no longer at a premium.
The benefits of totally self contained packages are huge. You'll probably find that the vast majority of your application is NOT duplicated data anyhow. It will be graphic resources, it's own code, etc.
Couple that with de-dup in modern filesystems (inline still a major overhead, but scheduled de-dup isn't a major problem) and the advantages to just linking to libraries everywhere are not so clear cut anymore.
Having lived with the OS X way of packaging for a few years, and dealt with both Linux, FreeBSD and Windows since the early 90s, I know which method I prefer.
That's a bunch of stupid shit for people who don't understand the difference between file caching and block caching. And think they can do a better job once a week than an intelligent controller which can analyze disk performance in real time and intelligently decide which individual blocks belong in the cache.
Maybe you should take a job at Netapp, EMC or another major enterprise storage vendor and tell them they're doing it wrong.
Slashdot Mirror
And you are free to monetize that video.
If that was the case, MS is dreaming. Google can turn their access off at a whim (problem solved), and MS would need to go to court and most definitely lose to try and force google to re-enable access to a free service that explicitly prohibits their behavior in the sites terms of service.
Bottom left of their page, link: terms.
Section 4b
Section 4j
Section 5b
I'm sure there are also other sections that could be used as justification by youtube to block MS user's access to the content without any problem at all.
Depends on how you quanity "better product". The only android device i've yet seen which even slightly interests me is the HTC one, due to its construction. It doesn't matter what the spec of a phone is or what it can do - if it feels like a turd to use, the experience is not going to be pleasant. Look up "haptics".
Pretty much. I'm sure it must be in google's terms of service somewhere that they "reserve the right to terminate service at any time for any reason", etc.
You want to bet the security of your site on that?
If not the kernel, maybe the C library. Which also isn't common to say, FreeBSD or Solaris.
Except it isn't the same software stack down to the operating system. The one thing all of these exploits have in common is they are running on Linux. What's to say there isn't a flaw in the kernel somewhere that is exposed via these web servers?
UI fluff maybe. I'm not talking about UI fluff.
Ubuntu does not have the same feature set as Windows 7. I was comparing a modern Linux distribution to Windows XP because the feature set is comparable. Release date doesn't really matter a shit, it's what you can actually DO with the operating system that is relevant.
Funny. I had XP running on 32MB when it came out. It wasn't blisteringly fast, but it was enough to burn CDs and stuff. It performed better with 32 MB than Windows 95 did with 4 MB which was the official requirement on release.
Uhh... typical mac installer. Fuck package mangers.... want to move the app to a different disk? Drag/drop. No dependency bullshit to deal with. Can run it from the network if i really wanted to.
Should do. There's no reason I can't install multiple copies of an OS X application by just dragging and dropping copies to different folders.
As opposed to the status quo, where if a fundamental library is replaced, it may cause breakage in every dependent app, resulting in a substantial burden.
Mac OS has been using application bundles since forever, and seems to manage just fine.
Cheap is relative. That tablet has about 120 times the storage capacity of my first Linux PC.
RAM and DISK became far, far cheaper than the time spent dealing with dependency bullshit incurred when you try to do something but can't because the feature is not included in the base OS.
So, why does Linux now need 256 MB of RAM pretty much as a minimum, to give a similar desktop experience to Windows XP which used to run in 2002 on 32 MB?
You install the individual application updates. Without needing to worry about any one of them breaking other dependencies.
Having lived with this approach on OS X for 3 years now, I am all for it. Install/uninstall for the vast majority of stuff is very basic drag/drop. Maybe clean up some saved preference plist files if you care about not having the configuration come back if you ever reinstall the app. I have not noticed any massive shortage of disk space. Most of an application's code is not shared, anyhow.
Probably less of a problem than installing a shared library update which borks a (or multiple) mission critical app. Repeatedly.
Install application patch. Yes it is more bandwidth. Yes it is more disk. Compatibility issues much less frequent.
I suspect the memory/CPU overhead for dedup is far larger than the disk/memory overhead for self-contained applications. Disk is cheap. RAM is cheap. Most of the application will be its OWN CODE, anyhow.
Yes. ZFS will do this, as will HAMMER. However, I suspect the gains REALLY aren't there. The core OS binaries (including all libraries) on a modern system account for what... 1-2% of the disk space? If that? The bulk of the code in your new application will be the new application. Even more disk will be consumed by the resources used only for that app (graphics, widget layouts, etc.).
Disk today is cheap. Having dealt with both linking (Windows, Unix) and self contained Applications (OS X), I much prefer the latter. Installation / un-installation is way, way easier. Compatibility issues are less common.
Which, given most people have upwards of half a terabyte of storage, and the OS consumes only 1% of that, storage space is no longer at a premium.
The benefits of totally self contained packages are huge. You'll probably find that the vast majority of your application is NOT duplicated data anyhow. It will be graphic resources, it's own code, etc.
Couple that with de-dup in modern filesystems (inline still a major overhead, but scheduled de-dup isn't a major problem) and the advantages to just linking to libraries everywhere are not so clear cut anymore.
Having lived with the OS X way of packaging for a few years, and dealt with both Linux, FreeBSD and Windows since the early 90s, I know which method I prefer.
For that 350 dollars, I can get 1.5 TB of hybrid storage AND a small boot SSD.
That's a bunch of stupid shit for people who don't understand the difference between file caching and block caching. And think they can do a better job once a week than an intelligent controller which can analyze disk performance in real time and intelligently decide which individual blocks belong in the cache.
Maybe you should take a job at Netapp, EMC or another major enterprise storage vendor and tell them they're doing it wrong.