They are saying: -They run an app store where they charge companies to post apps. Windows 8 comes with an app store which MS charges companies to post apps. This is a revenue loss for them if any companies choose the MS app store.
-The MS app store won't allow many/most of the types of apps they sell, meaning even if they wanted to "play nice" and sell games on both stores they couldn't.
-They fear that this is the beginning of an app lockdown, where ONLY "MS store" apps are allowed.
Due to all of the enhancements made to lower the memory and processor footprint of windows 8 most games will likely benchmark faster/better in windows 8 than in windows 7.
Old thread now, hopefully you'll take a look at your "replies" later:)
Two reasons:
1. To do ANYTHING useful in ASP (classic), you have to use an activeX object. DB calls/etc all go through activeX. The syntax for doing this is messy, and the objects don't always act the same as built in ASP functions (the same complaint PHP has), especially when they require c++ type structures like callbacks and output parameters.
Most people writing asp classic had no idea about what activeX is, how it works, and what you need to do with objects you create/etc.
2. It was very difficult to do code seperation in ASP. I never saw any full fledged templating systems, and doing even two layered coding (with a UI layer and business layer) was difficult at best. One place I worked at actually wrote their business logic in C++, called via activeX in asp, to enforce seperation. You couldn't really create your own business layer in pure asp.
ASP.NET isn't perfect (but it evolved nicely) but it fixed both of those issues.
At the time JSP was an EXCELLENT alternative. JSP gave you the same toolkit/language to write your business logic and presentation logic in while still letting you keep them seperate.
A more experienced tradesman knows the right tool for the job and doesn't attempt to halfass using the wrong one.
PHP is the right tool for getting a website up and running quickly without having to have a godo handle on programming.
PHP is the wrong tool for most other problems, and you can find your problem changing, hence many experienced developers avoid it.
When PHP was first launched, the major competitor was PERL. PHP let you have a simple html-looking file, and then put c-looking code inside of it, without crazy cgi shenanigans/templating libraries/etc. It was great for that reason, and I used it (other alternative was ASP classic... yuck). It was around RIGHT when the idea of the dynamic web was becoming popular, and so it's got a large footprint.
The software will work, you'll just need a breakout cable (which you already need anyways) which swaps the pins into the correct place for whatever interface board you'er using.
But simply detecting the RPI revision would be easy as well.
I understand that moms and pops buy DSLRs, but for their primary audience this is a bad thing. It's a feature that the more expensive cameras have more buttons. I started out an ameteur, and the 2 reasons I chose a canon 60d over a canon 550d were the size (the 60d is bigger, fits better in your hand) and that it had an extra wheel and about 5 more buttons.
Buttons/sliders I need to have available without looking: -ISO -focus (seperate from taking photo) -meter/take photo -choose focus point quickly -choose full autofocus quickly (so seperate from choosing a single point) -aperture -shutter -metering mode
- Easier ways to change settings that aren't changed frequently but are now buried in crazy hierarchical menus. - Time lapse photography (most DSLRs require an Intervalometer) - More complex control over slave flashes
I agree with all 3 of these 100%. It could also possibly give the ability for "better" or more customisable in-viewfinder UIs.
Time lapse is one that always comes up, and "magic lantern" supplies.
What do the angel investors know that the 63K that donated don't?
The angel investors don't want a console, they want a profit. A LUCRATIVE profit, given how many companies typical angel funds invest in to get a "hit" one.
As one of the 63k people backing ouya, I did so: -to buy a console -to back the idea
If all that comes of it is a few NES emulators, an FPS or two, and a youtube client then I'm happy enough with my $100 spent. Or if it starts a huge new console wave then I had one day one!
Either way I'm not looking for $500 out of my $100 investment, which is at a very low bar what angels would look for (if not more like 20:1 return possible).
Have at it: It's easy to root (and rooting won't void your warranty). Everything opens with standard screws. Hardware hackers can create their own peripherals, and connect via USB or Bluetooth. You want our hardware design? Let us know. We might just give it to you. Surprise us!"
You remember how all those "What do we need email for? We're a business, not a university! Send a Fax if you need it now, otherwise drop it in the post like everyone else." people sounded to you 15-20 years ago?
That's how you sound now.
You may not like it, I certainly don't, but this is life.
The time share mainframe only has one piece of the cloud puzzle, and that piece isn't even that relevant. "You only pay for what you use, but have a larger resource available if you need it."
The cloud is a LOT more than that. It's more to do with management and abstraction of concepts than about billing and capacity.
The core of cloud is "easy provisioning" IMO. Whether you're provisiong an entire server, a single app, a single PIECE of an app, or the data for an app, you don't care about the layers below that and you provision at a high level.
So I would say amazon EC2, with no other management, BARELY fits. EC2 + some scripting + their monitoring suite is more what "the cloud" is about.
The point is that you don't build 16 new red hat servers, load a mail server and all it's dependancies on 10 of them and apaache + php + a mysql client + a webmail front end on 6 of them, attach them to the network, configure them all in a cluster, set up SAN....
Instead you provision 200gb of storage. Then you provision 10 more mail servers. Then you provision 6 more webmail servers. Whatever "cloud" setup you have (it could just be a bunch of python scripts) handles imaging, packaging, networking, clustering, deployment etc. 2 hours later it's done, all with very few actions on the part of an admin (and possibly done automatically if you have a proactive elasticity setup).
"The Cloud" is just what GREAT sysadmins have always done (ones concerned with company performance as opposed to making their job irreplacable because they're the only ones who can provision a new server), but somewhat standardized for methodology.
Cloud is an easy description for where some layer is abstracted away to the level that it doesn't matter to implementers.
At work we now have a "private cloud." What this comprises is simply a VERY large VM infrastrcture with automated deployment and full time monitoring.
In the old world we would check a large chart of what apps were deployed on what servers, then place new apps on the least loaded servers. As loads changed our apps didn't move, we just were hosed unless we wanted people constantly installing and uninstalling apps on shared servers. Some servers were 2003R2, some 2008, some 2008R2, some 64bit, some 32 bit, etc. Some had shared components which one app upgrading might break, others didn't even have those components so you couldn't install new apps on it.
Now we simply say "we want instances of this app running." Our infrastructure (vmware + SCCM) spins up 3 default VMs and autodeploys the software. One will be in our backup datacenter, two in the primary. If load is too high we request more resources (more nodes, more ram, more cores). The entire systems management side of things is abstracted away.
One of the systems I manage has a 1.3TB ms sql server database. It absolutely flies.
The same SAN also hosts a few 8-10TB oracle databases with no issues.
What idiot shares spindle sets on a VM DB setup? OS goes to the shared pool, each DB gets its own set of LUNs depending on performance needs. This isn't rocket surgery.
If you're serious about virtualisation it's backed by a SAN anyways, which will get you many more IOPS than hitting a local disk ever would.
We virtualise almost everything now without issue by setting 0 contention. Our VM hosts are 40 core (4 socket) machines with 256GB ram. Need an 8 core VM with 64GB ram to run SQL Server? Fine.
We save BUCKETS on power, hardware, and licensing (Windows Server 2008 R2 datacenter licensing is per socket of the physical host) by virtualising.
The number one place you get bit errors is from loose/dodgy sata cables.
There's an interesting article on ZFS finding systematic corruption on one of the developer's home computers that he didn't know was occuring. He thought he'd found a ZFS bug!
In the end he replugged sata cables and was good to go again.
The app is calling sync, which is used to flush disk buffers and ensure a change is physically written to disk. btrfs does this safely, with barriers, as it should.
Should it simply ignore repeated sync() calls and NOOP? If not, what should it do?
If I write a program that tries to allocate 20GB of ram on startup and never uses it, then complain that "linux" is making this huge swap file and making my app slow, should they change the malloc/etc APIs to cater for my using them wrong?
Slashdot Mirror
Which games?
The biggest issue you'll run into is anything that was natively 16 bit (or used 16 bit libraries) if you're running 64bit.
For older dos games from the 80s/early 90s I advise virtualbox (you're already comparing to "wine" on linux).
No one is saying windows 8 is bad for gaming.
They are saying:
-They run an app store where they charge companies to post apps. Windows 8 comes with an app store which MS charges companies to post apps. This is a revenue loss for them if any companies choose the MS app store.
-The MS app store won't allow many/most of the types of apps they sell, meaning even if they wanted to "play nice" and sell games on both stores they couldn't.
-They fear that this is the beginning of an app lockdown, where ONLY "MS store" apps are allowed.
Due to all of the enhancements made to lower the memory and processor footprint of windows 8 most games will likely benchmark faster/better in windows 8 than in windows 7.
Not everyone has unlimited data plans, and not all areas have 100% coverage on the way to/from work (including tunnels/sparse areas/etc).
Old thread now, hopefully you'll take a look at your "replies" later :)
Two reasons:
1. To do ANYTHING useful in ASP (classic), you have to use an activeX object. DB calls/etc all go through activeX. The syntax for doing this is messy, and the objects don't always act the same as built in ASP functions (the same complaint PHP has), especially when they require c++ type structures like callbacks and output parameters.
Most people writing asp classic had no idea about what activeX is, how it works, and what you need to do with objects you create/etc.
2. It was very difficult to do code seperation in ASP. I never saw any full fledged templating systems, and doing even two layered coding (with a UI layer and business layer) was difficult at best. One place I worked at actually wrote their business logic in C++, called via activeX in asp, to enforce seperation. You couldn't really create your own business layer in pure asp.
ASP.NET isn't perfect (but it evolved nicely) but it fixed both of those issues.
At the time JSP was an EXCELLENT alternative. JSP gave you the same toolkit/language to write your business logic and presentation logic in while still letting you keep them seperate.
A more experienced tradesman knows the right tool for the job and doesn't attempt to halfass using the wrong one.
PHP is the right tool for getting a website up and running quickly without having to have a godo handle on programming.
PHP is the wrong tool for most other problems, and you can find your problem changing, hence many experienced developers avoid it.
When PHP was first launched, the major competitor was PERL. PHP let you have a simple html-looking file, and then put c-looking code inside of it, without crazy cgi shenanigans/templating libraries/etc. It was great for that reason, and I used it (other alternative was ASP classic... yuck). It was around RIGHT when the idea of the dynamic web was becoming popular, and so it's got a large footprint.
The software will work, you'll just need a breakout cable (which you already need anyways) which swaps the pins into the correct place for whatever interface board you'er using.
But simply detecting the RPI revision would be easy as well.
What's good about the pi:
-easy to use GPIO libraries were available day 1 (this is lacking on a LOT of the ARM SoC implementations)
-they worked pre-release with the XBMC to ensure that a "functioning" media center was available day 1
-tiny, cheap, powerful "enough" (you'll find better bang for buck, but not generally "cheaper")
-HDMI and ethernet onboard. Many don't come with either, requiring an adapter card
It's not perfect, but it is in a bit of a "sweet spot" for hobbiests who need a bit of power and a bit of easy.
You didn't buy it from the rasp pi foundation, you bought it from RS/Farnell/etc.
It's like blaming MS because your pre-ordered xbox at best buy didn't come in time while gamestop/etc still has tons.
- Touch screen vs ridiculous amounts of buttons.
I understand that moms and pops buy DSLRs, but for their primary audience this is a bad thing. It's a feature that the more expensive cameras have more buttons. I started out an ameteur, and the 2 reasons I chose a canon 60d over a canon 550d were the size (the 60d is bigger, fits better in your hand) and that it had an extra wheel and about 5 more buttons.
Buttons/sliders I need to have available without looking:
-ISO
-focus (seperate from taking photo)
-meter/take photo
-choose focus point quickly
-choose full autofocus quickly (so seperate from choosing a single point)
-aperture
-shutter
-metering mode
- Easier ways to change settings that aren't changed frequently but are now buried in crazy hierarchical menus.
- Time lapse photography (most DSLRs require an Intervalometer)
- More complex control over slave flashes
I agree with all 3 of these 100%. It could also possibly give the ability for "better" or more customisable in-viewfinder UIs.
Time lapse is one that always comes up, and "magic lantern" supplies.
I think you'll find you only need $199. The nexus 7 is similar hardware, and includes a battery/touchscreen/etc.
What do the angel investors know that the 63K that donated don't?
The angel investors don't want a console, they want a profit. A LUCRATIVE profit, given how many companies typical angel funds invest in to get a "hit" one.
As one of the 63k people backing ouya, I did so:
-to buy a console
-to back the idea
If all that comes of it is a few NES emulators, an FPS or two, and a youtube client then I'm happy enough with my $100 spent. Or if it starts a huge new console wave then I had one day one!
Either way I'm not looking for $500 out of my $100 investment, which is at a very low bar what angels would look for (if not more like 20:1 return possible).
From their kickstarter:
"
Hackers welcome.
Have at it: It's easy to root (and rooting won't void your warranty). Everything opens with standard screws. Hardware hackers can create their own peripherals, and connect via USB or Bluetooth. You want our hardware design? Let us know. We might just give it to you. Surprise us!"
Well, I'd more say for english speaking plus others units of billion:
http://en.wikipedia.org/wiki/File:World_map_of_long_and_short_scales.svg
It's mostly spanish and french (and derived) countries who use long scale.
If by "side load" you mean "install without going to the app store" then this is what a dev account allows you to do.
Plug in the iphone to USB, click deploy in xcode.
Guess what: When you launch visual studio it opens up the desktop. With as many windows as you want.
Even 2 minutes playing with windows 8 would show you that.
A tablet that you prop up and use a bluetooth keyboard and mouse with.
If only MS had thought of that and demoed one a few weeks ago...
You remember how all those "What do we need email for? We're a business, not a university! Send a Fax if you need it now, otherwise drop it in the post like everyone else." people sounded to you 15-20 years ago?
That's how you sound now.
You may not like it, I certainly don't, but this is life.
That's only income taxes. The US has absurdly high property taxes in most areas, plus state income taxes in most states.
You can also add medical insurance on top of that as for most countries it comes out of taxes.
There is only one "police", and they all act the same, have the same leadership structures, and the same operating proceedures.
The time share mainframe only has one piece of the cloud puzzle, and that piece isn't even that relevant. "You only pay for what you use, but have a larger resource available if you need it."
The cloud is a LOT more than that. It's more to do with management and abstraction of concepts than about billing and capacity.
The core of cloud is "easy provisioning" IMO. Whether you're provisiong an entire server, a single app, a single PIECE of an app, or the data for an app, you don't care about the layers below that and you provision at a high level.
So I would say amazon EC2, with no other management, BARELY fits. EC2 + some scripting + their monitoring suite is more what "the cloud" is about.
The point is that you don't build 16 new red hat servers, load a mail server and all it's dependancies on 10 of them and apaache + php + a mysql client + a webmail front end on 6 of them, attach them to the network, configure them all in a cluster, set up SAN....
Instead you provision 200gb of storage. Then you provision 10 more mail servers. Then you provision 6 more webmail servers. Whatever "cloud" setup you have (it could just be a bunch of python scripts) handles imaging, packaging, networking, clustering, deployment etc. 2 hours later it's done, all with very few actions on the part of an admin (and possibly done automatically if you have a proactive elasticity setup).
"The Cloud" is just what GREAT sysadmins have always done (ones concerned with company performance as opposed to making their job irreplacable because they're the only ones who can provision a new server), but somewhat standardized for methodology.
Cloud != outsourcing even.
Cloud is an easy description for where some layer is abstracted away to the level that it doesn't matter to implementers.
At work we now have a "private cloud." What this comprises is simply a VERY large VM infrastrcture with automated deployment and full time monitoring.
In the old world we would check a large chart of what apps were deployed on what servers, then place new apps on the least loaded servers. As loads changed our apps didn't move, we just were hosed unless we wanted people constantly installing and uninstalling apps on shared servers. Some servers were 2003R2, some 2008, some 2008R2, some 64bit, some 32 bit, etc. Some had shared components which one app upgrading might break, others didn't even have those components so you couldn't install new apps on it.
Now we simply say "we want instances of this app running." Our infrastructure (vmware + SCCM) spins up 3 default VMs and autodeploys the software. One will be in our backup datacenter, two in the primary. If load is too high we request more resources (more nodes, more ram, more cores). The entire systems management side of things is abstracted away.
One of the systems I manage has a 1.3TB ms sql server database. It absolutely flies.
The same SAN also hosts a few 8-10TB oracle databases with no issues.
What idiot shares spindle sets on a VM DB setup? OS goes to the shared pool, each DB gets its own set of LUNs depending on performance needs. This isn't rocket surgery.
Virtualisation != shared disk IO.
If you're serious about virtualisation it's backed by a SAN anyways, which will get you many more IOPS than hitting a local disk ever would.
We virtualise almost everything now without issue by setting 0 contention. Our VM hosts are 40 core (4 socket) machines with 256GB ram. Need an 8 core VM with 64GB ram to run SQL Server? Fine.
We save BUCKETS on power, hardware, and licensing (Windows Server 2008 R2 datacenter licensing is per socket of the physical host) by virtualising.
The number one place you get bit errors is from loose/dodgy sata cables.
There's an interesting article on ZFS finding systematic corruption on one of the developer's home computers that he didn't know was occuring. He thought he'd found a ZFS bug!
In the end he replugged sata cables and was good to go again.
What options does the FS have though?
The app is calling sync, which is used to flush disk buffers and ensure a change is physically written to disk. btrfs does this safely, with barriers, as it should.
Should it simply ignore repeated sync() calls and NOOP? If not, what should it do?
If I write a program that tries to allocate 20GB of ram on startup and never uses it, then complain that "linux" is making this huge swap file and making my app slow, should they change the malloc/etc APIs to cater for my using them wrong?