Well, a Linux port has been in progress for some time. If the VLC crew were to lend a hand, it would surely get done faster and with higher quality. I agree that cross-platform is essential.
Hopefully it wraps Avisynth -- it's got some incredible community-made scripts and plugins that are unmatched by anything else, but isn't newbie-friendly when it comes to what most people think of as "video editing".
Bitrate is only part of the equation -- the H.264 spec allows for a number of different ways to compress video, and it's up to the encoder to find out which is best for your video. Even in the same encoder, you can tweak dozens of settings in ways that dramatically change output quality -- usually a trade off between time and size.
x264 has beat every commercial encoder out there -- in some cases, on a level that would indeed render higher quality with half the bitrate.
Out of all the ones I've tried, Media Center ended up being the best fit for me. Others might have some more features, but Media Center had all the ones I cared about and most of the time implemented them better. The only problem I've run into is that their TV listings updater causes an ungodly amount of disk I/O and CPU usage for several minutes whenever it runs.
Almost everyone who's ever used a line of business app could have told you this. Good LOB apps will ask the question "how can we use PC to make the experience more efficient?". Bad ones will just say "paper sucks, lets make it digital!" have the exact same fields a paper would have, but make you type it. The bad ones might be marginally easier for management because of their rudimentary search and reporting, but are usually no different or even worse for the actual day to day users.
Yet management is continually suckered into thinking less paper == more efficient, and there are _a lot_ of bad LOB apps out there because of it.
I've used to make maybe 5 edits per year since Wikipedia began. Recently I've made a lot less, and it's not because I've run out of things to contribute.
Of the past 5 edits I've made, I think 4 of them have been tagged as a "good faith edit" and removed because they didn't live up to their new policies. Really, I understand their motivation -- they want everything to be as verifiable as possible. But I think this goes against what made Wikipedia big in the first place.
It used to be so quick and easy to add new information. Anyone who spotted an error was compelled to correct it. It brought the entire internet together as one big community. Now you have to stay caught up with their ever-changing policies, be prepared to defend an edit in the discussion page, etc. -- it's no longer quick and easy. It's no longer fun to contribute. It's more like actual work now. I'm glad that some people can still enjoy doing it because I find Wikipedia an invaluable resource, but as an 'infrequent' contributor, I have a lot of trouble finding the motivation to put up with it any more.
Windows Vista and 7 do this too. Applications can set a flag to tell the window manager that it is high-DPI aware, and get nice big sharp windows. Apps without this flag are rendered at 96dpi and scaled up to avoid any issues with dumb programs.
The migration happens within the same table. In a schemaless environment, you simply store objects. JSON seems to be popular for them, so imagine you store a bunch of objects like {"Id":1,"Value":2}, {"Id":2,"Value":3}, etc.
If you decide you want to add a new feature "foo" to your app and it needs a new attribute to work, you don't need to tell the database anything. Just keep your old code around that knows how to read the old objects, and the next time you need to update one, update it as {"Id":1,"Value":2,"foo":"bar"}. Even after this "foo" attribute is added to the first object, the second one is still perfectly valid being just {"Id":2,"Value":3}.
It is up to the application to enforce any schema, if that's what you choose to do -- the database doesn't care what you put in it. Either way you aren't forced to make your data tabular, and that is where the big win comes along in expressing your data more naturally.
These databases are all schemaless, so it's not like they could use an established RDBMS... they had to make something new. I was trying to give an example of why they wouldn't bother implementing something like JOIN in something new that they planned to scale from the beginning.
I'd actually be pretty stoked to find a schemaless DB that uses mostly standard SQL, because I find schemaless makes a lot of sense for use beyond cloud-level scalability. Most of the time they let you store things in a more natural, accessible way than what tables provide.
But a big benefit they have for scalability (and I suspect the reason those companies went schemaless) is that if you decide you want to change your application-defined object schema, you don't have to copy everything to a new table or ALTER the existing one. If you've got terabytes of data, it can be well worth it to simply keep code around that knows how to read the old object type and update them on demand.
There's a reason Google, Amazon, and Microsoft all designed their cloud databases without SQL -- it has a lot of features that don't scale well when your data spans a crap ton of servers. Imagine a website that does several JOIN queries for each page view -- now if you've got data spanning 50 servers, that's a hell of a lot of I/O that will be very hard to scale. When you take out these extra features, you end up not having much more than the basics -- usually just a simple insert, update, and delete with very limited transaction support. Without all the bells and whistles, there's no point in pretending you support SQL anymore.
Think of the current concurrency push, and how most people consider it very challenging to do correctly, and are hoping some magic silver bullet comes along to fix it all. The old designs don't translate to multi-core very well. This is the same thing. Cloud databases require a fundamental redesign of how you structure and query your data. The only difference is, concurrency can usually be added in steps. With Cloud databases, it's usually all-in or nothing with no hand holding.
I think a bigger problem is that the name "NoSQL" sounds like a direct attack at SQL. Really, it's just a stupid name for a larger mantra that most programmers try to abide by: use what's best for the job. SQL is great for a lot of jobs, but not all. Maybe someone will come along with that "magic silver bullet" for SQL that makes it super-scalable in all situations, but until then, we've now got more options for when it's not.
A lot of today's FPSes seem to prefer a ping of less than 100ms. Many of them become very frustrating to play at 150ms -- I can only assume this is due to whatever cheat protection they use forcing them to use less and less lag compensation, and forcing them to run less of the simulation locally.
I live on the west coast, and a lot of the people I play with live on the east coast. So when we have the option of buying a server, we get one somewhere in the middle so that we all have pings in the 50-100ms range instead of the 150-200ms range. Taking this option away will really, really suck.
The ebook readers can get away with this cheaply because ebooks don't take up much space. Games on the other hand can be quite large, and I imagine the next-gen games meant to compete with the iPhone 3GS (which has more powerful hardware than both the current DSi and and PSP Go) will be even larger. Can Nintendo really front the costs to provide access to this service without increasing game price?
Most clients have you set a fixed upload speed. Some try to do this automatically, while most have you set it manually. This isn't perfect - if you set it to use 80% of your upload, and you are using more than 20%, things will get slow. If you use less than 20%, you'll have some amount idle and being wasted. Some rely on something like monitoring ping to some specific service.. if ping is higher, throttle back. If ping is low, increase speed. Again this isn't perfect because it relies on a single host and route to determine your speed.
uTorrent's new protocol requires no action from the user, no automatic bandwidth tests, and no outside service. It is designed to always use the optimal speed, while never interfering with foreground tasks.
It has been a while since I read it, and when I read it I was very very tired, but my understanding is that it tags each packet with a high-precision send time. So if we have two packets, A and B, A will sent at 100ms and B will be sent at 300ms. So you know they were sent 200ms apart. The _receiver_ then notices that he receives them 400ms apart, so there is 200ms of lag which means it should be throttled back. It tries to keep the amount of lag 50ms. Again, I could be completely wrong:D
Since it is based on UDP and not TCP, it also solves the problem of Comcast sending fake RST packets to make each client think they wanted to disconnect from eachother.
"Cloud" is a pretty stupid name, one that bugs me almost as much as "AJAX", but it's hurt even more by being associated with two things at once.
The first is simply a client->server connection, or perhaps hosting your data online. This, I think, doesn't need a new name. The old names were working fine.
The second, and far more interesting, is for much more complex systems that are marking a move from managed server hosting to scalable application hosting. These guys design their systems from the ground up to scale your applications quickly, efficiently, and reliably across a pool of servers. By doing this all in one place, hopefully with a lower cost than what it would take for you to do something similar on your own. I think this is a significantly different approach that it needs a new name to differentiate it from what we're used to. This is also what TFA seems to mean when they say "cloud".
I'm currently evaluating these cloud services for my company -- the idea that I can simply focus on writing good code and let someone else worry about starting new servers when usage spikes, replacing ones that break, adding more storage for the database, etc... it is very tempting. The cons? They all use proprietary APIs that seem similar on the surface but in the end are different enough that you really need to specialize your code for their service -- if you ever want to move your app over to something else, it's not going to be simple.
I hope this TS is real -- a true hardware upgrade is exactly what these portable systems need. The iPhone 3GS is a great deal more powerful than the PSPs and DS. I wonder how worried Sony is, considering their new PSP Go doesn't have any hardware capability upgrades (other than Bluetooth).
You have balloons, streamers, a deck of cards, and a puzzle. It's like they want you to throw a lame children's birthday party. I really have to wonder how this got through without anyone noticing how terrible it is. And the goodies you're supposed to give to guests? Two of them are cards for antivirus software. I guess that's being responsible, but pointing out ways to fix your software's faults is still a funny way to market a new product.
So long as the advert spots are equivalent to the ones in real life, I agree. I've never minded the occasional racing game that includes billboards with real adverts. But who wants to bet EA types will go overboard with it? Better not to even start down that slippery slope -- if you want to make games more realistic with ads, make them fake ads like GTA does.
They are stopping their nForce line of chipsets (as in, northbridge/southbridge). I couldn't be the only one to see this coming a mile away, could I? Before AMD acquired ATI, they and Nvidia were perfect partners. After that they became a lot less relevant. With Intel and AMD producing their own well regarded "gamer-grade" products for some time now, I can see why Nvidia sees little point in fighting.
I don't know the first thing about the stock exchange so I won't presume to know what is required to code one efficiently. If.NET was suitable for this platform, the programmers botched it. If it wasn't suitable, then the programmers still botched it by making a stupid environment choice.
As ironic as this is given Microsoft's big LSE advertising in the past, if they're having trouble with their current set up it's the fault of whatever programmers wrote it and not of.NET. Hopefully they'll have some better programmers working on it this time.
Does anyone know what development languages this supports? My current phone is Windows Mobile and I'd have a hard time switching to anything that didn't let me use real C++.
shoeless people in Africa? We have Java, as well as Python and various other languages on Linux for the niche Mono wants to fill.
I believe Miguel was referring to Open Source within Microsoft. RMS is the first salesman seeing no potential for Open Source, and Miguel is the second who chooses to fight the odds and attempt to bring shoes (Open Source) to a shoeless society.
I believe Miguel was somewhat wrong, though -- RMS deals in Free Software, not Open Source. To him, Free Software is the absolute and anything else is a waste of time. It is more like Shoe Company A (Free Software) visiting Africa and deciding Africa is nefarious when they choose to go with Shoe Companies B and C (other Open Source licenses) instead.
with the popularity of DD-WRT and others, i'm surprised it took wifi companies this long to try to make money on it. linksys made the WRT-54GL a long time ago but didn't try to promote custom firmwares.
DLLs also allow better use of your CPU's cache. You might link one program as pure static and see it not lose speed, or maybe even see it go faster. But if all the programs out there started doing it, I'd be really curious to see if it helped or hurt.
Slashdot Mirror
Well, a Linux port has been in progress for some time. If the VLC crew were to lend a hand, it would surely get done faster and with higher quality. I agree that cross-platform is essential.
Hopefully it wraps Avisynth -- it's got some incredible community-made scripts and plugins that are unmatched by anything else, but isn't newbie-friendly when it comes to what most people think of as "video editing".
Bitrate is only part of the equation -- the H.264 spec allows for a number of different ways to compress video, and it's up to the encoder to find out which is best for your video. Even in the same encoder, you can tweak dozens of settings in ways that dramatically change output quality -- usually a trade off between time and size.
x264 has beat every commercial encoder out there -- in some cases, on a level that would indeed render higher quality with half the bitrate.
Out of all the ones I've tried, Media Center ended up being the best fit for me. Others might have some more features, but Media Center had all the ones I cared about and most of the time implemented them better. The only problem I've run into is that their TV listings updater causes an ungodly amount of disk I/O and CPU usage for several minutes whenever it runs.
Almost everyone who's ever used a line of business app could have told you this. Good LOB apps will ask the question "how can we use PC to make the experience more efficient?". Bad ones will just say "paper sucks, lets make it digital!" have the exact same fields a paper would have, but make you type it. The bad ones might be marginally easier for management because of their rudimentary search and reporting, but are usually no different or even worse for the actual day to day users.
Yet management is continually suckered into thinking less paper == more efficient, and there are _a lot_ of bad LOB apps out there because of it.
I've used to make maybe 5 edits per year since Wikipedia began. Recently I've made a lot less, and it's not because I've run out of things to contribute.
Of the past 5 edits I've made, I think 4 of them have been tagged as a "good faith edit" and removed because they didn't live up to their new policies. Really, I understand their motivation -- they want everything to be as verifiable as possible. But I think this goes against what made Wikipedia big in the first place.
It used to be so quick and easy to add new information. Anyone who spotted an error was compelled to correct it. It brought the entire internet together as one big community. Now you have to stay caught up with their ever-changing policies, be prepared to defend an edit in the discussion page, etc. -- it's no longer quick and easy. It's no longer fun to contribute. It's more like actual work now. I'm glad that some people can still enjoy doing it because I find Wikipedia an invaluable resource, but as an 'infrequent' contributor, I have a lot of trouble finding the motivation to put up with it any more.
Windows Vista and 7 do this too. Applications can set a flag to tell the window manager that it is high-DPI aware, and get nice big sharp windows. Apps without this flag are rendered at 96dpi and scaled up to avoid any issues with dumb programs.
The migration happens within the same table. In a schemaless environment, you simply store objects. JSON seems to be popular for them, so imagine you store a bunch of objects like {"Id":1,"Value":2}, {"Id":2,"Value":3}, etc.
If you decide you want to add a new feature "foo" to your app and it needs a new attribute to work, you don't need to tell the database anything. Just keep your old code around that knows how to read the old objects, and the next time you need to update one, update it as {"Id":1,"Value":2,"foo":"bar"}. Even after this "foo" attribute is added to the first object, the second one is still perfectly valid being just {"Id":2,"Value":3}.
It is up to the application to enforce any schema, if that's what you choose to do -- the database doesn't care what you put in it. Either way you aren't forced to make your data tabular, and that is where the big win comes along in expressing your data more naturally.
These databases are all schemaless, so it's not like they could use an established RDBMS... they had to make something new. I was trying to give an example of why they wouldn't bother implementing something like JOIN in something new that they planned to scale from the beginning.
I'd actually be pretty stoked to find a schemaless DB that uses mostly standard SQL, because I find schemaless makes a lot of sense for use beyond cloud-level scalability. Most of the time they let you store things in a more natural, accessible way than what tables provide.
But a big benefit they have for scalability (and I suspect the reason those companies went schemaless) is that if you decide you want to change your application-defined object schema, you don't have to copy everything to a new table or ALTER the existing one. If you've got terabytes of data, it can be well worth it to simply keep code around that knows how to read the old object type and update them on demand.
There's a reason Google, Amazon, and Microsoft all designed their cloud databases without SQL -- it has a lot of features that don't scale well when your data spans a crap ton of servers. Imagine a website that does several JOIN queries for each page view -- now if you've got data spanning 50 servers, that's a hell of a lot of I/O that will be very hard to scale. When you take out these extra features, you end up not having much more than the basics -- usually just a simple insert, update, and delete with very limited transaction support. Without all the bells and whistles, there's no point in pretending you support SQL anymore.
Think of the current concurrency push, and how most people consider it very challenging to do correctly, and are hoping some magic silver bullet comes along to fix it all. The old designs don't translate to multi-core very well. This is the same thing. Cloud databases require a fundamental redesign of how you structure and query your data. The only difference is, concurrency can usually be added in steps. With Cloud databases, it's usually all-in or nothing with no hand holding.
I think a bigger problem is that the name "NoSQL" sounds like a direct attack at SQL. Really, it's just a stupid name for a larger mantra that most programmers try to abide by: use what's best for the job. SQL is great for a lot of jobs, but not all. Maybe someone will come along with that "magic silver bullet" for SQL that makes it super-scalable in all situations, but until then, we've now got more options for when it's not.
A lot of today's FPSes seem to prefer a ping of less than 100ms. Many of them become very frustrating to play at 150ms -- I can only assume this is due to whatever cheat protection they use forcing them to use less and less lag compensation, and forcing them to run less of the simulation locally.
I live on the west coast, and a lot of the people I play with live on the east coast. So when we have the option of buying a server, we get one somewhere in the middle so that we all have pings in the 50-100ms range instead of the 150-200ms range. Taking this option away will really, really suck.
The ebook readers can get away with this cheaply because ebooks don't take up much space. Games on the other hand can be quite large, and I imagine the next-gen games meant to compete with the iPhone 3GS (which has more powerful hardware than both the current DSi and and PSP Go) will be even larger. Can Nintendo really front the costs to provide access to this service without increasing game price?
Most clients have you set a fixed upload speed. Some try to do this automatically, while most have you set it manually. This isn't perfect - if you set it to use 80% of your upload, and you are using more than 20%, things will get slow. If you use less than 20%, you'll have some amount idle and being wasted. Some rely on something like monitoring ping to some specific service.. if ping is higher, throttle back. If ping is low, increase speed. Again this isn't perfect because it relies on a single host and route to determine your speed.
uTorrent's new protocol requires no action from the user, no automatic bandwidth tests, and no outside service. It is designed to always use the optimal speed, while never interfering with foreground tasks.
It has been a while since I read it, and when I read it I was very very tired, but my understanding is that it tags each packet with a high-precision send time. So if we have two packets, A and B, A will sent at 100ms and B will be sent at 300ms. So you know they were sent 200ms apart. The _receiver_ then notices that he receives them 400ms apart, so there is 200ms of lag which means it should be throttled back. It tries to keep the amount of lag 50ms. Again, I could be completely wrong :D
Since it is based on UDP and not TCP, it also solves the problem of Comcast sending fake RST packets to make each client think they wanted to disconnect from eachother.
"Cloud" is a pretty stupid name, one that bugs me almost as much as "AJAX", but it's hurt even more by being associated with two things at once.
The first is simply a client->server connection, or perhaps hosting your data online. This, I think, doesn't need a new name. The old names were working fine.
The second, and far more interesting, is for much more complex systems that are marking a move from managed server hosting to scalable application hosting. These guys design their systems from the ground up to scale your applications quickly, efficiently, and reliably across a pool of servers. By doing this all in one place, hopefully with a lower cost than what it would take for you to do something similar on your own. I think this is a significantly different approach that it needs a new name to differentiate it from what we're used to. This is also what TFA seems to mean when they say "cloud".
I'm currently evaluating these cloud services for my company -- the idea that I can simply focus on writing good code and let someone else worry about starting new servers when usage spikes, replacing ones that break, adding more storage for the database, etc... it is very tempting. The cons? They all use proprietary APIs that seem similar on the surface but in the end are different enough that you really need to specialize your code for their service -- if you ever want to move your app over to something else, it's not going to be simple.
Has anyone written a comparison of GCD, Intel Thread Building Blocks, and VC++ 2010's own task-based concurrency library?
I hope this TS is real -- a true hardware upgrade is exactly what these portable systems need. The iPhone 3GS is a great deal more powerful than the PSPs and DS. I wonder how worried Sony is, considering their new PSP Go doesn't have any hardware capability upgrades (other than Bluetooth).
You have balloons, streamers, a deck of cards, and a puzzle. It's like they want you to throw a lame children's birthday party. I really have to wonder how this got through without anyone noticing how terrible it is. And the goodies you're supposed to give to guests? Two of them are cards for antivirus software. I guess that's being responsible, but pointing out ways to fix your software's faults is still a funny way to market a new product.
So long as the advert spots are equivalent to the ones in real life, I agree. I've never minded the occasional racing game that includes billboards with real adverts. But who wants to bet EA types will go overboard with it? Better not to even start down that slippery slope -- if you want to make games more realistic with ads, make them fake ads like GTA does.
They are stopping their nForce line of chipsets (as in, northbridge/southbridge). I couldn't be the only one to see this coming a mile away, could I? Before AMD acquired ATI, they and Nvidia were perfect partners. After that they became a lot less relevant. With Intel and AMD producing their own well regarded "gamer-grade" products for some time now, I can see why Nvidia sees little point in fighting.
I don't know the first thing about the stock exchange so I won't presume to know what is required to code one efficiently. If .NET was suitable for this platform, the programmers botched it. If it wasn't suitable, then the programmers still botched it by making a stupid environment choice.
As ironic as this is given Microsoft's big LSE advertising in the past, if they're having trouble with their current set up it's the fault of whatever programmers wrote it and not of .NET. Hopefully they'll have some better programmers working on it this time.
Does anyone know what development languages this supports? My current phone is Windows Mobile and I'd have a hard time switching to anything that didn't let me use real C++.
I believe Miguel was referring to Open Source within Microsoft. RMS is the first salesman seeing no potential for Open Source, and Miguel is the second who chooses to fight the odds and attempt to bring shoes (Open Source) to a shoeless society.
I believe Miguel was somewhat wrong, though -- RMS deals in Free Software, not Open Source. To him, Free Software is the absolute and anything else is a waste of time. It is more like Shoe Company A (Free Software) visiting Africa and deciding Africa is nefarious when they choose to go with Shoe Companies B and C (other Open Source licenses) instead.
with the popularity of DD-WRT and others, i'm surprised it took wifi companies this long to try to make money on it. linksys made the WRT-54GL a long time ago but didn't try to promote custom firmwares.
DLLs also allow better use of your CPU's cache. You might link one program as pure static and see it not lose speed, or maybe even see it go faster. But if all the programs out there started doing it, I'd be really curious to see if it helped or hurt.