This seems to be Sony's hedging of their bets that maybe handheld gaming devices are in their dying days. They get to turn the Vita into a pseudo-console/PS4 accessory and keep developers on the Vita platform in general. Maybe this is what Nintendo should be doing instead of a 2DS?
My understanding is the libmkv terminate was the DoS portion. The SWF use-after-free would indeed be vulnerable, but is also within ffmpeg. While it would be nice - and in their best interests - if VLC fixed it upstream, it should have been reported as an ffmpeg issue imo.
Not only that, the whole article is trollish. They're not "circling the drain" or anything like that; rather they saw that Nook sales sucked, ate up their profits from their standard business, and decided to kill the Nook line. Also known as "adapting to market conditions" - exactly what they should do!
My understanding is the original developer claimed to be able to not use the goofy scanline hack if he'd been on a larger ROM. Maybe Ms. Pac Man was a 16K ROM rather than 8K?
That's the link I was thinking of. I was slightly off too; a commenter had the Thinkpad EDID issue, and it was set to a 5:4 resolution on a 720p display.
Isn't that more of a problem with the circuitry inside the TV? I remember reading a bunch of stuff by mjg about how the EDID and such inside TVs are a complete joke, if present at all. One anecdote he listed was a 32" 720p-class TV with a Thinkpad (yes, Thinkpad) 4:3 EDID.
FWIW, while FreeBSD does not yet have KMS, it is definitely being worked on. I think the goal is to have KMS entirely running on BSD so all these video drivers can work there too. It's unfortunate that the BSDs are effectively held back now by this, but the driver model did necessitate a change. Devs had wrung out all they could out of the old-style drivers.
The reason given for releasing them all at once is that while there is an order they expect them to be viewed, they can be viewed in random order to get the stories in different perspectives. Portia de Rossi said something to the effect of if you watch her episode first, Lucille ends up looking particularly bitchy, but if you watch Jessica Walters' episode first, Lindsay ends up looking bitchy.
I'm with you; I love that, some 10 years on, I can still just fire up SC4 from time to time and play around for a little while. Then, if I'm changing PCs, all I have to do is copy a directory full of files to the new box. Sad that this is now a "killer feature", being able to control your data.
Even some 64-bit EFI machines won't run it, because they have Intel graphics. Anything with the 965 series (such as X3100) is unsupported for one reason - there was never a 64-bit kext for it. This is also what kept these machines from booting a 64-bit kernel in 10.7. So if Apple and/or Intel would actually create a 64-bit kext for the 965 series, a whole bunch more machines would run it just fine.
FWIW, this might also get your Mini up and running, as there are definitely ways to get around the 32-bit EFI problem. But until they create that kext (read: never), it's not gonna happen.
It can be tougher to learn, but like any other language it wholly depends on your exposure to it. I'd say the biggest problem Latin-based speakers will have at first is learning the differences between intiial, medial, and final forms of each glyph. Then, learning the differences between those within the Arabic-like languages -- Farsi, Dari, etc. To be able to accomplish basic recognition, I would say no more than 3 months should be plenty. But that's true of most languages -- getting basic comprehension typically takes a short time, but mastery can often be a lifetime endeavor.
Geez, that UET is particularly nasty in its side-effects.
We have emissions to thank for a lot of the computerization of cars. Everything you described, as you know, comes down to the computer retarding the engine timing. This is done solely to keep the vehicle from spewing emissions, or at least the computer is programmed to *think* that's what the car is about to do and it reacts accordingly. I notice you'll get similar behavior with a bad mass airflow sensor, sometimes inefficient cat but that ties into O2, etc.
I'm with you -- lose all the sensors, let's go back to pure mechanical.
While it is true that you cannot just drop in a used BCM plug-n-play style, (with the same feature/option codes) you can typically use a 30-minute procedure to reset the ignition and other systems. The sucky thing is the procedure can vary depending on the age of the BCM, but it's still workable.
That will at least get a matching-option-code BCM to work in a different vehicle, except the radio. As far as I know, GM is the only party able to unlock a locked radio. Part of me wonders if, with reverse engineering, it would be possible to crash the BCM CPU and force the radio back to unlocked.
What is unclear to me is, what does the GM tool actually do? Everything technical I've read about Passkey implies that the key is write-once, but the GM dealers seem to have a way to clear that key. If it truly *can* be erased electronically, couldn't a strong EM signal at least corrupt, if not wipe, the BCM PROMs?
Three words -- Body Control Module. I don't know a damned thing about Jaguars, but with GM vehicles in general they all have a Body Control Module installed. Anything that isn't directly related to the powertrain is controlled by the BCM (incidentally, the powertrain is controlled by the Powertrain Control Module). In many GM vehicles, the BCM can be communicated with via the radio; this is to set certain user options like how long the headlamps will remain illuminated after exiting the vehicle. In the event that something goes wrong with the BCM, the radio will lock because it gets put into an anti-theft state, and typically the car will not start. All because a single capacitor on a shitty little Motorola board got cooked, for example.
Then, even if you get a used BCM with the same option codes as the one you're replacing, the radio will remain in an anti-theft state because the thinking of the designers (I guess) was that people would start swapping BCMs just to steal radios -- dumb.
GM, of course, has a tool to reprogram BCMs, but even they say there's a 50/50 shot their programming will render the BCM unusable. From my limited research of the boards they use, it seems there is little if any CRC done in any shape or form, so it sounds like the board will happily write bad or invalid data to the PROM.
Again, I don't know how a Jaguar design works, but there are vehicles where the radio does indeed affect other parts of the vehicle, much to the dismay of owners and dealers alike.
I'm assuming you're on iOS 4.0.x. In that case, it is best right now to check on Saurik's twitter (http://twitter.com/saurik) as he is the developer of MobileTerminal. He currently has known bugs - including a nasty MobileSubstrate crash, sounds like what you're seeing - when running on iOS 3.2.x and 4.0.x. MobileTerminal last worked reliably on version 3.1 and earlier.
Also, don't forget Konfabulator. Actually it seems they do this every couple releases for OSX... 10.2 had Sherlock (Watson), 10.4 had Dashboard (Konfabulator). I guess they really DO have lightweight and movable teams -- their copying folks now work on iOS!
Hey thanks for the link! A mess isn't a problem; hell, it's better than what I have -- nothing!
I could be wrong about -deinterlace using cycles when it isn't necessary; I'm very much an amateur at this stuff still. For me, I've been using mencoder with -vf pullup,softskip for telecine'd content. It's slower, but the results (IMO) look better than ffmpeg, particularly for animation. For the mencoder tasks, I use a modified version of the script found at this blog: http://blog.dastrup.com/?p=34
First, ffmpeg's deinterlacer kinda sucks. Especially if you're working with NTSC broadcast (60000/1001fps) content, because really you want to be doing a pullup. Since in your example you're using 24000/1001, I guess it's progressive content. In that case, do you really need to deinterlace at all? If you do, you might be interested in the "top" parameter (see the manpage) for setting which field is first in interlaced content; usually it won't be necessary, but it's nice to have the ability. Just throw "-top -1" somewhere in there so it'll always autodetect, or if you want to get fancy, leverage ffprobe to tell you which field is first; I think you can do that with 'ffprobe -show_streams'.
Second, I find a crf of 18 to 20 to be ideal for DVD content, particularly fast motion. Higher values tend to *just barely* starve the encoder of data during high/fast motion; it's more noticeable on a scaled-up display IMO.
What are the opinions of other ffmpeg+x264 users out there?
With regards to moderation, it seems in the past 6 to 12 months, suddenly the same people not only keep getting mod points, but they get 10-20 of them at a time! When your "average" moderator only gets 5 points roughly once every two months, it's easy to see what has happened lately to moderation. As for me? I guess I pissed off slashcode a while back when tagging was still new, and one day a bunch of people (myself included) gave every story a "dontmebro" tag. dont-agw-mebro would be perfect for this one!
Want a fun sandbox experience with U8? Google u8cheat.exe. There were so many cheating and debugging options in that game you could set up just about anything, sandbox-style. I used to have more fun playing around with the cheats than I did with the actual game.
Slashdot Mirror
This seems to be Sony's hedging of their bets that maybe handheld gaming devices are in their dying days. They get to turn the Vita into a pseudo-console/PS4 accessory and keep developers on the Vita platform in general. Maybe this is what Nintendo should be doing instead of a 2DS?
My understanding is the libmkv terminate was the DoS portion. The SWF use-after-free would indeed be vulnerable, but is also within ffmpeg. While it would be nice - and in their best interests - if VLC fixed it upstream, it should have been reported as an ffmpeg issue imo.
Not only that, the whole article is trollish. They're not "circling the drain" or anything like that; rather they saw that Nook sales sucked, ate up their profits from their standard business, and decided to kill the Nook line. Also known as "adapting to market conditions" - exactly what they should do!
My understanding is the original developer claimed to be able to not use the goofy scanline hack if he'd been on a larger ROM. Maybe Ms. Pac Man was a 16K ROM rather than 8K?
http://mjg59.dreamwidth.org/8705.html
That's the link I was thinking of. I was slightly off too; a commenter had the Thinkpad EDID issue, and it was set to a 5:4 resolution on a 720p display.
Isn't that more of a problem with the circuitry inside the TV? I remember reading a bunch of stuff by mjg about how the EDID and such inside TVs are a complete joke, if present at all. One anecdote he listed was a 32" 720p-class TV with a Thinkpad (yes, Thinkpad) 4:3 EDID.
FWIW, while FreeBSD does not yet have KMS, it is definitely being worked on. I think the goal is to have KMS entirely running on BSD so all these video drivers can work there too. It's unfortunate that the BSDs are effectively held back now by this, but the driver model did necessitate a change. Devs had wrung out all they could out of the old-style drivers.
The reason given for releasing them all at once is that while there is an order they expect them to be viewed, they can be viewed in random order to get the stories in different perspectives. Portia de Rossi said something to the effect of if you watch her episode first, Lucille ends up looking particularly bitchy, but if you watch Jessica Walters' episode first, Lindsay ends up looking bitchy.
I'm with you; I love that, some 10 years on, I can still just fire up SC4 from time to time and play around for a little while. Then, if I'm changing PCs, all I have to do is copy a directory full of files to the new box. Sad that this is now a "killer feature", being able to control your data.
The same guy developed both - the PSP one and the iOS 1.0 one.
Undoing accidental mod
Even some 64-bit EFI machines won't run it, because they have Intel graphics. Anything with the 965 series (such as X3100) is unsupported for one reason - there was never a 64-bit kext for it. This is also what kept these machines from booting a 64-bit kernel in 10.7. So if Apple and/or Intel would actually create a 64-bit kext for the 965 series, a whole bunch more machines would run it just fine.
FWIW, this might also get your Mini up and running, as there are definitely ways to get around the 32-bit EFI problem. But until they create that kext (read: never), it's not gonna happen.
Replying to remove accidental troll mod.
I'm unsure why you're modded troll; I thought it was very funny.
Seriously though, while they won't remove USB, isn't it likely they'll remove the ability to use USB hubs?
It can be tougher to learn, but like any other language it wholly depends on your exposure to it. I'd say the biggest problem Latin-based speakers will have at first is learning the differences between intiial, medial, and final forms of each glyph. Then, learning the differences between those within the Arabic-like languages -- Farsi, Dari, etc. To be able to accomplish basic recognition, I would say no more than 3 months should be plenty. But that's true of most languages -- getting basic comprehension typically takes a short time, but mastery can often be a lifetime endeavor.
Geez, that UET is particularly nasty in its side-effects.
We have emissions to thank for a lot of the computerization of cars. Everything you described, as you know, comes down to the computer retarding the engine timing. This is done solely to keep the vehicle from spewing emissions, or at least the computer is programmed to *think* that's what the car is about to do and it reacts accordingly. I notice you'll get similar behavior with a bad mass airflow sensor, sometimes inefficient cat but that ties into O2, etc.
I'm with you -- lose all the sensors, let's go back to pure mechanical.
While it is true that you cannot just drop in a used BCM plug-n-play style, (with the same feature/option codes) you can typically use a 30-minute procedure to reset the ignition and other systems. The sucky thing is the procedure can vary depending on the age of the BCM, but it's still workable.
That will at least get a matching-option-code BCM to work in a different vehicle, except the radio. As far as I know, GM is the only party able to unlock a locked radio. Part of me wonders if, with reverse engineering, it would be possible to crash the BCM CPU and force the radio back to unlocked.
What is unclear to me is, what does the GM tool actually do? Everything technical I've read about Passkey implies that the key is write-once, but the GM dealers seem to have a way to clear that key. If it truly *can* be erased electronically, couldn't a strong EM signal at least corrupt, if not wipe, the BCM PROMs?
Three words -- Body Control Module. I don't know a damned thing about Jaguars, but with GM vehicles in general they all have a Body Control Module installed. Anything that isn't directly related to the powertrain is controlled by the BCM (incidentally, the powertrain is controlled by the Powertrain Control Module). In many GM vehicles, the BCM can be communicated with via the radio; this is to set certain user options like how long the headlamps will remain illuminated after exiting the vehicle. In the event that something goes wrong with the BCM, the radio will lock because it gets put into an anti-theft state, and typically the car will not start. All because a single capacitor on a shitty little Motorola board got cooked, for example.
Then, even if you get a used BCM with the same option codes as the one you're replacing, the radio will remain in an anti-theft state because the thinking of the designers (I guess) was that people would start swapping BCMs just to steal radios -- dumb.
GM, of course, has a tool to reprogram BCMs, but even they say there's a 50/50 shot their programming will render the BCM unusable. From my limited research of the boards they use, it seems there is little if any CRC done in any shape or form, so it sounds like the board will happily write bad or invalid data to the PROM.
Again, I don't know how a Jaguar design works, but there are vehicles where the radio does indeed affect other parts of the vehicle, much to the dismay of owners and dealers alike.
I'm assuming you're on iOS 4.0.x. In that case, it is best right now to check on Saurik's twitter (http://twitter.com/saurik) as he is the developer of MobileTerminal. He currently has known bugs - including a nasty MobileSubstrate crash, sounds like what you're seeing - when running on iOS 3.2.x and 4.0.x. MobileTerminal last worked reliably on version 3.1 and earlier.
Also, don't forget Konfabulator. Actually it seems they do this every couple releases for OSX... 10.2 had Sherlock (Watson), 10.4 had Dashboard (Konfabulator). I guess they really DO have lightweight and movable teams -- their copying folks now work on iOS!
Hey thanks for the link! A mess isn't a problem; hell, it's better than what I have -- nothing!
I could be wrong about -deinterlace using cycles when it isn't necessary; I'm very much an amateur at this stuff still. For me, I've been using mencoder with -vf pullup,softskip for telecine'd content. It's slower, but the results (IMO) look better than ffmpeg, particularly for animation. For the mencoder tasks, I use a modified version of the script found at this blog: http://blog.dastrup.com/?p=34
Nice script, but two things..
First, ffmpeg's deinterlacer kinda sucks. Especially if you're working with NTSC broadcast (60000/1001fps) content, because really you want to be doing a pullup. Since in your example you're using 24000/1001, I guess it's progressive content. In that case, do you really need to deinterlace at all? If you do, you might be interested in the "top" parameter (see the manpage) for setting which field is first in interlaced content; usually it won't be necessary, but it's nice to have the ability. Just throw "-top -1" somewhere in there so it'll always autodetect, or if you want to get fancy, leverage ffprobe to tell you which field is first; I think you can do that with 'ffprobe -show_streams'.
Second, I find a crf of 18 to 20 to be ideal for DVD content, particularly fast motion. Higher values tend to *just barely* starve the encoder of data during high/fast motion; it's more noticeable on a scaled-up display IMO.
What are the opinions of other ffmpeg+x264 users out there?
With regards to moderation, it seems in the past 6 to 12 months, suddenly the same people not only keep getting mod points, but they get 10-20 of them at a time! When your "average" moderator only gets 5 points roughly once every two months, it's easy to see what has happened lately to moderation. As for me? I guess I pissed off slashcode a while back when tagging was still new, and one day a bunch of people (myself included) gave every story a "dontmebro" tag. dont-agw-mebro would be perfect for this one!
Want a fun sandbox experience with U8? Google u8cheat.exe. There were so many cheating and debugging options in that game you could set up just about anything, sandbox-style. I used to have more fun playing around with the cheats than I did with the actual game.
Now, how about a collision? Let's see what other "sentences" can end up at the same md5sum :)