It might be bloated and slow. But it is also easily extendable and human readable.
Human readable yes, extendable no. Well, it's not extendable in any meaningful way. Even though it looks like it on a quick look, if you read the spec you quickly realize there really is no generic structure to a message -- you cannot parse an HTTP request if you do not fully understand it. Even custom headers like the commonly used X-Foo-Whatever are impossible to parse or even simply ignore, so implementations just use an unspecified de-facto parsing and pray to the web gods that it works.
This makes HTTP parsers very complicated to write correctly and even moreso if you want to build a library for others to extend HTTP with. This isn't a text VS binary issue, but simply a design flaw. Hopefully HTTP 2.0 fixes this.
As they say, HTTP 1.1 isn't going anywhere -- this'll be a dual-stack web with 2.0 being used by new browsers and 1.1 still available for old browsers/people.
Modern barcodes like PDF417, QR, and Data Matrix have robust error correction built into their spec and can take a lot of damage. If you're really wanting to print stuff on paper as a backup, these are definitely your best bet.
Personally, I'd just encrypt and shove into a few different off-site backups.
LA's public transportation system covers a phenomenally large area, and is ubiquitous and cheap. I used to ride it all the time before moving to Chicago, where I'm still a little amazed at how much smaller and more expensive it is.
I'm surprised any 3rd party transportation system can make enough money to survive in LA, but I'm not surprised by the cease-and-desist. Public transportation is kept cheap by subsidies and limiting other services. For instance, you can't hail a cab -- it's illegal for them to pull over for you. These services are likely seen as pulling and end run-around the regulations that licensed taxi companies need to follow.
From my understanding, the LEDs in question are infrared, invisible to the eye. They're meant to foil infrared cameras "night vision." Wearing them in the day would be pointless, and at night, you still wouldn't see the LED light.
This will still work during the day, mostly -- the majority of cameras out there lack IR filters and show it as purple. Bright enough LEDs would almost certainly be able to wash out a picture.
That was clearly hyperbole, though node.js does have one interesting attribute that deserves some praise: It was designed from the start to support only asynchronous I/O. Basically, it was built for maximum scalability in the embarrassingly parallel environment it is meant to service.
The form of async Node.js supports isn't anything special. It's been around in many languages for a long time, and in fact there are some far more performant implementations as well as some far better models (like C# 5.0) which make node.js look like spaghetti code. The unique part is that by emphasizing async right from the get-go, all the stuff that is built on it supports async as well. One of the most difficult things about using async in say C++ or C# is that 99.9% of the existing libraries do not properly support it. Async begins to fall apart if you block too much, and you're basically forced to unless you want to rewrite all these supporting libraries.
But, it's still Javascript. Who wants to write a complicated app in Javascript? It's a pretty terrible language. And so I won't be using Node.js for anything in production, but I suppose it does provide a quick point for web devs to jump into writing backend code without needing to learn a new language, so I can understand its popularity.
Supporting XP is especially complicated for IE, because starting with IE9 they've rewritten the rendering engine to use Direct2D and DirectWrite (Vista only), which depend on Direct3D 10 (Vista only), which depends on WDDM 1.1 (Vista only). Should they be backporting all of these APIs and kernel-mode code as well? Or maybe just maintain a large GDI fallback just for XP?
XP is 12 years old, and its last major update is 5 years old. How long should they continue to develop new software and major updates for a platform?
It's not like they're holding people back: they can switch to Chrome or Firefox if they want a modern experience, and the IE they have is the one they need for compatibility with IE-only websites.
Watch when we spend six hours fixing a machine somebody botched horribly because we told them to push button A then button B then button C, but they pushed button B then button A then button C. For the third time.
I despise this. Whoever designs these systems to be so fragile that they break if you don't use them in a very specific order is the problem. There are certainly some dumb users out there, but there are even more dumb systems which are completely unhelpful.
People need to learn to take time to make things easy, accessible, and fool-proof. Design for the user, not the engineer.
Ebooks open the floor to self-publishers wanting to reach a mass audience, which cuts out the established publishers entirely. This is already quite prolific on Amazon. Making the popular ebooks expensive is an effective way to kill off a platform before it starts -- why would anyone buy a Kindle when the books they know are significantly more expensive on it?
Ebooks are certainly more profitable, but they've already invested a lot in physical manufacturing and distribution. Becoming popular too quickly might force them to scale down operations at too fast a pace, and pricing is a way to artificially dampen it.
They're money-grubbing whores and trying to pass the ebook experience off as a premium one because you can carry around hundreds of them, highlight passages, and dozens of other features that 90% of people won't use, while ignoring the core reading experience which is still sub-par even when comparing to cheap mass-market paperbacks.
Why not use a benchmark that renders some SSL encoded web pages? Because the benchmark is going to be bottlenecked by the network stack and the rendering engine. Not the tiny percentage of the time the CPU spends doing AES.
This benchmark is not quite relevant to the average user, but SSL can be a large bottleneck in web servers -- it is certainly relevant there.
I see this problem time and again, where a programmer that just doesnt get it is trying to use SSE
Do you teach? I don't see that very often outside of SIMD newbies. Curiosities aside, as I said:
It's really not something you want to do, but sometimes there are no good alternatives.
There are some algorithms, like EWA/Jinc image resampling, which simply don't translate well to SIMD without gather support. Keeping with the image processing theme, sRGB gamma decompression will be lightning fast with a L1-friendly 1KiB LUT -- I bet faster than any low-precision approximation in use today.
This is not about trying to fit AoS into a SIMD world. This is about enabling some things in SIMD which simply weren't possible before. Newbies will no doubt use it improperly, but then those with experience and perhaps a little imagination will use it to make code that screams.
Better AoS support shouldn't really be discounted, either -- some standard data formats outside of the programmer's control are really unfriendly to SIMD, and scatter/gather might not give an 8x speedup in processing it but it will certainly help.
A more immediately useful feature is backwards-compatible hardware lock elision. Before taking a lock, you emit an instruction which is a NOP for older CPUs but causes Haswell to ignore the lock and create an implicit transaction. Instant scalability improvement to just about every app out there with contention, without having to distribute Haswell-specific binaries.
My favorite feature, though, is scatter/gather support for SIMD. Scatter/gather is very important because up until now loading memory from several locations for SIMD use has been a pain in the ass involving costly shuffles and often requires you to load more than you actually immediately wanted, possibly forcing you to spill registers. It's really not something you want to do, but sometimes there are no good alternatives. I'll be super interested to see benchmarks taking this into account.
Amazon has that exact sort of deal if you want to list items with them: The item's price at Amazon must be the lowest. Your price at other places can match it, but not be any lower.
(Doesn't make Apple doing it any better or worse, of course. They're both being douchebags.)
I know it fell out of favor for new projects when Google Code / CodePlex / GitHub came on the scene with their Web 2.0 design hotness and minimalistic feature sets, but SourceForge is still around and continues to improve without taking any features away.
The actual reason for this happening is that Microsoft's renderer heavily clamps the font's outline to be on pixel boundaries. The point at the top of an "i" literally becomes a square, nothing to do with having fewer shades available.
They actually changed this in Vista, with DirectWrite adding support for sub-pixel rendering (basically, removing the clamping). Many people reacted badly to it because it made things look a bit less sharp in the same way you dislike FreeType, and so very few apps actually turn this feature on.
In practice people cant tell the difference between 6 bit and 10 bit colour.
Some particularly problematic scenes involving mostly a single color should still benefit, but I tend to agree especially for movie watching. The real purpose of moving to 10-bit components is to accommodate the ~3x larger gamut without introducing banding compared to 8-bit.
Content won't exist that uses it so it WILL be "relegated to photographers and graph (sic) designers", standard or not.
Except every 4K/8K UHDTV broadcast will be using Rec. 2020, in this wide gamut, and cameras have been able to capture images outside of the sRGB gamut for some time. The content will exist.
The side effect of wide gamut displays displaying common content in non-color managed environments is that it looks worse, not better.
Right. This is because the de-facto standard 8-bit output is sRGB. These monitors are doing something outside of this standard and require proper color management to make things look correct.
The difference here is that we've got a fairly clean slate with 10-/12-bit UHDTV and Rec. 2020. There's no reason for any device to assume sending sRGB in this case will give the correct results. The TVs/monitors will use it. The content will use it. HEVC has a Main 10 profile added specifically for use with UHDTV.
Today's HD content won't look the least bit better on a wide gamut display, it could only look worse.
With 10-bit processing you should be able to do color management without any perceptible loss in quality.
4K/8K will sell UHDTV. But the best benefit, a gem rarely mentioned: it features a hugely increased gamut and 10 or 12-bit (10-bit mandatory minimum) component depth. The image will look more life-like than any of the common TVs available today, and it won't be relegated to photographers and graph designers: it'll be standard.
This is what happens when games are made by gamers. It's mainly the big, long-disconnected companies that think DRM will save their games from pirates; everyone else just acknowledges it with a little fun.
That it'll take 2x-3x longer than it takes in my head. If there are no spec changes (i can dream, right?) or other surprises, maybe put that down to 1.5x.
When given a project, I'm sure most people will have a macro-level architecture thought up within minutes. It all seems so easy at that point! If you're lucky you get to spend a little more time in thought before being asked for a time estimate. If you're unlucky, well... in those cases I just multiply by 3. Underpromise, overdeliver and all that.
They have the tech. It wouldn't take long to add credit card processing to HBO GO. Clearly something is holding them back -- they're able to make more money from the cable companies alone than they would from allowing anyone to pay for streaming. Likely due to cable companies threatening to not pay as much if that were to happen.
I can see the resulting files having better print characteristics, if the detectors sense to the levels close to the characteristics of ink used for prints, but I don't think that's going to help at the display the photographer will be using to manipulate the images.
You can losslessly, mathematically translate between this and RGB (certainly not sRGB) and CMYK. But that's just math. Printing is difficult due to the physical variables of the subtractive color model. The more money you throw at it -- that is to say, the better and more inks and quality of paper you use -- the better it gets. No new physical or mathematical colorspace will improve color reproduction.
For solid state drives a physical destruction might be required, but I'm still not convinced anyone could beat the challenge with a HDD if it were still happening today.
Then again, why not just encrypt everything. No need to do anything when you're done with the data, then.
VP8 was already designed to work around patent restricions
Anyone who follows codecs will know that VP8 is extremely similar to H.264 baseline, enough that patent infringement is an almost certainty. As much as we wish that wasn't true, it is. Their "work around" was to give identical technologies different names and put their fingers into their ears screaming "LA LA LA LA LA" denying any patent infringement. When they realized this wasn't going to work, Google finally licensed the patents from MPEG LA.
The more interesting (though not entirely surprising) bit from this news is that MPEG LA might not actually own all the patents required for H.264 to work.
I agree to a point. Using good headphones and specific songs, I can tell a 192kbps VBR MP3 from FLAC.
You need to train for it, though. For me, 192kbps VBR is transparent in nearly all cases -- I really need to listen for specific things in order to hear it, and only in some songs. Before learning what to listen for, 160kbps VBR was completely transparent to me.
I keep all my music in FLAC at home, but really only because disk space is cheap and if I ever feel like moving from MP3 to Vorbis/AAC on my DAP, I can do so without re-ripping.
Slashdot Mirror
It might be bloated and slow. But it is also easily extendable and human readable.
Human readable yes, extendable no. Well, it's not extendable in any meaningful way. Even though it looks like it on a quick look, if you read the spec you quickly realize there really is no generic structure to a message -- you cannot parse an HTTP request if you do not fully understand it. Even custom headers like the commonly used X-Foo-Whatever are impossible to parse or even simply ignore, so implementations just use an unspecified de-facto parsing and pray to the web gods that it works.
This makes HTTP parsers very complicated to write correctly and even moreso if you want to build a library for others to extend HTTP with. This isn't a text VS binary issue, but simply a design flaw. Hopefully HTTP 2.0 fixes this.
As they say, HTTP 1.1 isn't going anywhere -- this'll be a dual-stack web with 2.0 being used by new browsers and 1.1 still available for old browsers/people.
Modern barcodes like PDF417, QR, and Data Matrix have robust error correction built into their spec and can take a lot of damage. If you're really wanting to print stuff on paper as a backup, these are definitely your best bet.
Personally, I'd just encrypt and shove into a few different off-site backups.
LA's public transportation system covers a phenomenally large area, and is ubiquitous and cheap. I used to ride it all the time before moving to Chicago, where I'm still a little amazed at how much smaller and more expensive it is.
I'm surprised any 3rd party transportation system can make enough money to survive in LA, but I'm not surprised by the cease-and-desist. Public transportation is kept cheap by subsidies and limiting other services. For instance, you can't hail a cab -- it's illegal for them to pull over for you. These services are likely seen as pulling and end run-around the regulations that licensed taxi companies need to follow.
From my understanding, the LEDs in question are infrared, invisible to the eye. They're meant to foil infrared cameras "night vision." Wearing them in the day would be pointless, and at night, you still wouldn't see the LED light.
This will still work during the day, mostly -- the majority of cameras out there lack IR filters and show it as purple. Bright enough LEDs would almost certainly be able to wash out a picture.
That was clearly hyperbole, though node.js does have one interesting attribute that deserves some praise: It was designed from the start to support only asynchronous I/O. Basically, it was built for maximum scalability in the embarrassingly parallel environment it is meant to service.
The form of async Node.js supports isn't anything special. It's been around in many languages for a long time, and in fact there are some far more performant implementations as well as some far better models (like C# 5.0) which make node.js look like spaghetti code. The unique part is that by emphasizing async right from the get-go, all the stuff that is built on it supports async as well. One of the most difficult things about using async in say C++ or C# is that 99.9% of the existing libraries do not properly support it. Async begins to fall apart if you block too much, and you're basically forced to unless you want to rewrite all these supporting libraries.
But, it's still Javascript. Who wants to write a complicated app in Javascript? It's a pretty terrible language. And so I won't be using Node.js for anything in production, but I suppose it does provide a quick point for web devs to jump into writing backend code without needing to learn a new language, so I can understand its popularity.
Supporting XP is especially complicated for IE, because starting with IE9 they've rewritten the rendering engine to use Direct2D and DirectWrite (Vista only), which depend on Direct3D 10 (Vista only), which depends on WDDM 1.1 (Vista only). Should they be backporting all of these APIs and kernel-mode code as well? Or maybe just maintain a large GDI fallback just for XP?
XP is 12 years old, and its last major update is 5 years old. How long should they continue to develop new software and major updates for a platform?
It's not like they're holding people back: they can switch to Chrome or Firefox if they want a modern experience, and the IE they have is the one they need for compatibility with IE-only websites.
Watch when we spend six hours fixing a machine somebody botched horribly because we told them to push button A then button B then button C, but they pushed button B then button A then button C. For the third time.
I despise this. Whoever designs these systems to be so fragile that they break if you don't use them in a very specific order is the problem. There are certainly some dumb users out there, but there are even more dumb systems which are completely unhelpful.
People need to learn to take time to make things easy, accessible, and fool-proof. Design for the user, not the engineer.
Why not use a benchmark that renders some SSL encoded web pages? Because the benchmark is going to be bottlenecked by the network stack and the rendering engine. Not the tiny percentage of the time the CPU spends doing AES.
This benchmark is not quite relevant to the average user, but SSL can be a large bottleneck in web servers -- it is certainly relevant there.
I see this problem time and again, where a programmer that just doesnt get it is trying to use SSE
Do you teach? I don't see that very often outside of SIMD newbies. Curiosities aside, as I said:
It's really not something you want to do, but sometimes there are no good alternatives.
There are some algorithms, like EWA/Jinc image resampling, which simply don't translate well to SIMD without gather support. Keeping with the image processing theme, sRGB gamma decompression will be lightning fast with a L1-friendly 1KiB LUT -- I bet faster than any low-precision approximation in use today.
This is not about trying to fit AoS into a SIMD world. This is about enabling some things in SIMD which simply weren't possible before. Newbies will no doubt use it improperly, but then those with experience and perhaps a little imagination will use it to make code that screams.
Better AoS support shouldn't really be discounted, either -- some standard data formats outside of the programmer's control are really unfriendly to SIMD, and scatter/gather might not give an 8x speedup in processing it but it will certainly help.
A more immediately useful feature is backwards-compatible hardware lock elision. Before taking a lock, you emit an instruction which is a NOP for older CPUs but causes Haswell to ignore the lock and create an implicit transaction. Instant scalability improvement to just about every app out there with contention, without having to distribute Haswell-specific binaries.
My favorite feature, though, is scatter/gather support for SIMD. Scatter/gather is very important because up until now loading memory from several locations for SIMD use has been a pain in the ass involving costly shuffles and often requires you to load more than you actually immediately wanted, possibly forcing you to spill registers. It's really not something you want to do, but sometimes there are no good alternatives. I'll be super interested to see benchmarks taking this into account.
Amazon has that exact sort of deal if you want to list items with them: The item's price at Amazon must be the lowest. Your price at other places can match it, but not be any lower. (Doesn't make Apple doing it any better or worse, of course. They're both being douchebags.)
I know it fell out of favor for new projects when Google Code / CodePlex / GitHub came on the scene with their Web 2.0 design hotness and minimalistic feature sets, but SourceForge is still around and continues to improve without taking any features away.
The actual reason for this happening is that Microsoft's renderer heavily clamps the font's outline to be on pixel boundaries. The point at the top of an "i" literally becomes a square, nothing to do with having fewer shades available.
They actually changed this in Vista, with DirectWrite adding support for sub-pixel rendering (basically, removing the clamping). Many people reacted badly to it because it made things look a bit less sharp in the same way you dislike FreeType, and so very few apps actually turn this feature on.
In practice people cant tell the difference between 6 bit and 10 bit colour.
Some particularly problematic scenes involving mostly a single color should still benefit, but I tend to agree especially for movie watching. The real purpose of moving to 10-bit components is to accommodate the ~3x larger gamut without introducing banding compared to 8-bit.
Content won't exist that uses it so it WILL be "relegated to photographers and graph (sic) designers", standard or not.
Except every 4K/8K UHDTV broadcast will be using Rec. 2020, in this wide gamut, and cameras have been able to capture images outside of the sRGB gamut for some time. The content will exist.
The side effect of wide gamut displays displaying common content in non-color managed environments is that it looks worse, not better.
Right. This is because the de-facto standard 8-bit output is sRGB. These monitors are doing something outside of this standard and require proper color management to make things look correct.
The difference here is that we've got a fairly clean slate with 10-/12-bit UHDTV and Rec. 2020. There's no reason for any device to assume sending sRGB in this case will give the correct results. The TVs/monitors will use it. The content will use it. HEVC has a Main 10 profile added specifically for use with UHDTV.
Today's HD content won't look the least bit better on a wide gamut display, it could only look worse.
With 10-bit processing you should be able to do color management without any perceptible loss in quality.
4K/8K will sell UHDTV. But the best benefit, a gem rarely mentioned: it features a hugely increased gamut and 10 or 12-bit (10-bit mandatory minimum) component depth. The image will look more life-like than any of the common TVs available today, and it won't be relegated to photographers and graph designers: it'll be standard.
Don't forget Serious Sam 3, who's DRM manifested as an invulnerable pink scorpion.
This is what happens when games are made by gamers. It's mainly the big, long-disconnected companies that think DRM will save their games from pirates; everyone else just acknowledges it with a little fun.
That it'll take 2x-3x longer than it takes in my head. If there are no spec changes (i can dream, right?) or other surprises, maybe put that down to 1.5x.
When given a project, I'm sure most people will have a macro-level architecture thought up within minutes. It all seems so easy at that point! If you're lucky you get to spend a little more time in thought before being asked for a time estimate. If you're unlucky, well... in those cases I just multiply by 3. Underpromise, overdeliver and all that.
I think Zardoz would also be a good candidate.
There are ways to monetize free viewers.
They have the tech. It wouldn't take long to add credit card processing to HBO GO. Clearly something is holding them back -- they're able to make more money from the cable companies alone than they would from allowing anyone to pay for streaming. Likely due to cable companies threatening to not pay as much if that were to happen.
I can see the resulting files having better print characteristics, if the detectors sense to the levels close to the characteristics of ink used for prints, but I don't think that's going to help at the display the photographer will be using to manipulate the images.
You can losslessly, mathematically translate between this and RGB (certainly not sRGB) and CMYK. But that's just math. Printing is difficult due to the physical variables of the subtractive color model. The more money you throw at it -- that is to say, the better and more inks and quality of paper you use -- the better it gets. No new physical or mathematical colorspace will improve color reproduction.
Anyone remember The Great Zero Challenge?
For solid state drives a physical destruction might be required, but I'm still not convinced anyone could beat the challenge with a HDD if it were still happening today.
Then again, why not just encrypt everything. No need to do anything when you're done with the data, then.
VP8 was already designed to work around patent restricions
Anyone who follows codecs will know that VP8 is extremely similar to H.264 baseline, enough that patent infringement is an almost certainty. As much as we wish that wasn't true, it is. Their "work around" was to give identical technologies different names and put their fingers into their ears screaming "LA LA LA LA LA" denying any patent infringement. When they realized this wasn't going to work, Google finally licensed the patents from MPEG LA.
The more interesting (though not entirely surprising) bit from this news is that MPEG LA might not actually own all the patents required for H.264 to work.
I agree to a point. Using good headphones and specific songs, I can tell a 192kbps VBR MP3 from FLAC.
You need to train for it, though. For me, 192kbps VBR is transparent in nearly all cases -- I really need to listen for specific things in order to hear it, and only in some songs. Before learning what to listen for, 160kbps VBR was completely transparent to me.
I keep all my music in FLAC at home, but really only because disk space is cheap and if I ever feel like moving from MP3 to Vorbis/AAC on my DAP, I can do so without re-ripping.