It's no great surprise 3D TV died, while it was arguably better than the older red/blue system it still was a long shot at best; still at least it probably helped push along other developments during the cash splurge.
What however is looking to stick around and become more popular is the '360 degree' vision videos.
Perhaps if 3D rises again, they might just go straight for the neural implant - we'll see in another 25~30 years I suppose.
C for modern microcontrollers is a good mix. Easy to access bit-level operations (port control, bit bashing etc) but providing structured programming framework with easier debugging (libraries, function calls, interrupts, even portability to other architectures).
I code ASM for quite a few when needed (ie things like the Attiny5/10 due to stack limitations ) but realistically doing it in C makes the end-to-end development process a lot smoother.
The compiler will out optimise the human in almost all cases, and if you have a specific block that you absolutely have to code in ASM then you can simply inline it within the C. If you need to ilk out that last few bytes in the flash then it's often cheaper to bump to the next uC size than pay someone to stuff around for days trying to out optimise (most optimisations will tend to be through algorithmic / process changes), not to mention dealing with the inevitable quirks/pains when someone tries to modify it.
C isn't really used / chosen any more to participate in the international dick-waving contest. I hope in many ways C is falling out of favour with people just trying to "be cool" or using it for tasks that it's ill suited for.
Regardless of C falling in popularity (if legitimate) it's unlikely to be buried any time in the next 50 years given its use in the core of everything from OSs to 1K microcontroller firmware.
Sounds like someone got a good bucket sized serving from the gravy trough here to have this happen. The outcome is most likely going to be poor on efficiency and higher than "anticipated" on maintenance ( which will be no shock ), and the next bucket sized serving of gravy will be served up to "research" the issues further and facilitate someone's lifestyle.
Initially we were thinking it was a ball/pad issue, but we've found even with the jobs redone and bracing on the chassis to stiffen up the area, there's still a non-insignificant number of units coming back with the same issue (across multiple shops, not just one). Starting to look a bit more like an issue with either the actual chip itself or the PCB, not to say it definitely isn't a ball issue but it's not clear cut.
Either way, it's good to see Apple now admit the issue, though the $149 cost is still a bit of a cop-out ( no worries, people who have made a good income with the replacements will continue to do so for a while then ).
If it's using some sort of handshake likely it shouldn't need more than 100nA to get things started, a dedicated chip on the socket/device side, size clearly isn't an issue since they cram a couple in to the plug itself.
As I understand it, it's only signal level power ( under 1mA) until the lanes are selected and switched for power. It may even be 1-wire (like Magsafe).
Sadly I cannot find any documents at this point to backup my statements.
AFAIK, the controller/management chip in the plug portion will not let full power through until it's confirmed the connection itself, part of the orientation smarts.
Similar to their magsafe as well (Macbook has to validate things before charger is told to deliver full power ).
Courage would be USB spec ditching their obsession with fragile tongue-on-equipment configuration and going with lightning type design. Not keen on everything Apple does but the lightning connector is good engineering against human incompetence. Empirically* micro / USB-C are a lot more prone to user-damage, hell people manage to break USB-A sockets.. how the hell!?
The lifetime environmental impact of lithium storage technology is less than that of alternatives. Our usage of lead-acid batteries is more toxic and we have a tremendous number of those being discarded each day, without even accounting for the impacts of fossil fuels involved in power generation and transport.
The mass penalty / structural workarounds, and the low incentive (given how few fatal crashes there are with air travel) will see this being pushed to the "amusing thought" pile and no real further. Much like massive parachutes from a long time ago ( some people use them on their smaller planes though ).
Out of all the major brands that I repair, iPhones are typicall the cheapest and easiest to repair and spare parts are plentiful ( though not Apple-blessed ), and contrary to people still thinking of the first iPhones, since the 3/3GS they've always used screws for assemblies; yes, there's some 2 sided tape as an addition to halt screen wiggles on the 4/4S but beyond that iPhones are very repairable. HTC, stuff that, throw it out, 2 sided tape, kapton tape, crazy clips. Samsung, used to be good with the S2, 3, 4 and similar era Notes, but as of the S5 it's a disaster and the replacement screens cost a small country. Nokia has some very nice to repair models and replacement screens are sensibly priced by few people seem to have them.
Now, if we talk about iPads/iPods, I absolutely agree, nightmares:(
Agreed. Went looking for some eInk solutions for a few projects a while back, ended up just giving up as there seems to be this great void between the accessible ( 2~2.5" max ) and the "Good luck buddy, no help for you!" 6"+ displays. Ever since eInk really captured the developer imagination, it feels like it's been some ludicrously guarded secret club to get your hands on a decent unit at a sane price.
Ideally I'd still love to see a reasonably fast refresh (10Hz) 13~15" eInk display.
At this point it still just waits for you to upgrade the iOS or factory-reset before it'll lock out with E53.
I do a fair number of these repairs each day, usually people who have smashed their screens so badly that they've lost the home button (or torn it).
These days we simply warn them of the impending doom and give them the option of how they'd like to proceed (repair and never upgrade, or get their data and ditch the phone).
The GPLv3 is the best thing for free software, because it forces everything to be free. The rest will die a slow death due to feature and user attrition.
Like that time Windows and OS X used to roam the earth.
I greatly appreciate the open source development world, writing, funding and using it every day, but it will inevitably live in the shadows of the commercial world from a consumer perspective for reasons that have nothing to do with the source code or licence.
Just wanted to jump on the bandwagon and agree with your view on this matter. It's already hard enough to get your foot in the door for establishing a presence, and time/effort is a rare commodity such that people will discard an option if it looks like it's going to be more work on top of simply learning how to integrate it in to their project.
Likely someone will end up writing a BSD-modified/Apache/MIT licenced implementation of this and *maybe* from that the standard might have more success in gaining a foothold (assuming there isn't cloud of subtly-broken implementations to poison the well), the downside for the original-standard though will be then that the majority of developers will be following someone else's developments.
All of my own FOSS projects have been set free in the world as BSD-modified.
I'm just getting on board with BlueCherryDVR, and I've made a mention of a couple of things that would be nice to have (all duly noted on their forum);
* Motion detection marking/denoting on continuous video record
* Adjustable brightness/contrast on the client
* Better motion detection algorithm ( the current one is excessively sensitive, even at minimal settings )
I concur too about the installation process. BCDVR was an absolute pleasure compared to the pains I endured to get ZM installed; BCDVR is also a lot more stable it seems, both server and remote client.
I really don't see the internet collapsing from him walking away. If it was a legitimate issue it'd be quickly picked up by another party, commercial or otherwise. I'd suggest he does just walk away from it. Even if a lot of money was pushed his way, I'm willing to speculate that he's burned out from all those hours (100/wk?) over the years and now wants to just set things up for a new person, step out, and close the door; been there, done that.
If we ceased having any NTP servers, then there's a more likely internet collapse scenario. The current NTP software seems to have been doing pretty good over the last couple of decades; or is there something that's progressively changing?
I appreciate that the guy has put a lot of work in to it, a lot of us (OSS developers) have and it's a passion more than anything else; if you get money out of it, it's a bonus, but one should never engage in it thinking there'll be any rewards other than seeing that the software itself grows and maybe a little bit of acknowledgement of what you've done. The OSS community can't get all up in arms with disgust when large corps use our software to help them progress, while not all corps give back to all projects, there's still a lot of stuff that is given back, or donated, even when not legally required.
The ethics of earning money off the back of OSS could be debated, but that's a whole different sphere. A lot of us already donate a lot of money already to various OSS projects as a nice feel-good gesture as well as a way to encourage further developments.
If people don't want megacorps making a "shit-tonne" of cash out of their work then they need to be forward thinking and put a clause in the licence to prevent this.
The software author has the power to control the licence. No one put a gun to their head and told them to release it free.
There's plenty of cases of electronics misbehaving due to exposure to strong light. Glass enveloped diodes (such as signal diodes) can be notorious for it, as can the black plastic encased units if the light is strong enough.
Small bare CoG (Chip on Glass) LCD panels will crash / hang when you use the flash on the camera taking photos of them in operation ( same reason, the controller die is exposed ).
It's not EM-pulse or xrays causing the problem, just good ole silicon junctions being exposed to intense light:)
Ignoring the actual Pi debate - Darn those people who still use 68HC11 and 6502 controllers. You seem experienced enough to likely know yourself that if you've got a chip that's cheap enough not to ruin your BOM, that is available/in-production, does the job, has a solid toolchain, and coupled with years of development experience globally and in-house, then you don't just throw that all in the trash because something newer/faster/smaller/cheaper comes out.
Half the time I think a lot of people jump to the newest stuff because they don't like having their exclusivity eroded. Using older stuff makes sense when your product doesn't need cutting edge and you want to have a wealth of experience / dependability to draw from.
As for me, I'm still enjoying the AVR Tiny4/5/9/10 series, it's like the modern 555;)
Slashdot Mirror
It's no great surprise 3D TV died, while it was arguably better than the older red/blue system it still was a long shot at best; still at least it probably helped push along other developments during the cash splurge.
What however is looking to stick around and become more popular is the '360 degree' vision videos.
Perhaps if 3D rises again, they might just go straight for the neural implant - we'll see in another 25~30 years I suppose.
C for modern microcontrollers is a good mix. Easy to access bit-level operations (port control, bit bashing etc) but providing structured programming framework with easier debugging (libraries, function calls, interrupts, even portability to other architectures).
I code ASM for quite a few when needed (ie things like the Attiny5/10 due to stack limitations ) but realistically doing it in C makes the end-to-end development process a lot smoother.
The compiler will out optimise the human in almost all cases, and if you have a specific block that you absolutely have to code in ASM then you can simply inline it within the C. If you need to ilk out that last few bytes in the flash then it's often cheaper to bump to the next uC size than pay someone to stuff around for days trying to out optimise (most optimisations will tend to be through algorithmic / process changes), not to mention dealing with the inevitable quirks/pains when someone tries to modify it.
C isn't really used / chosen any more to participate in the international dick-waving contest. I hope in many ways C is falling out of favour with people just trying to "be cool" or using it for tasks that it's ill suited for.
Regardless of C falling in popularity (if legitimate) it's unlikely to be buried any time in the next 50 years given its use in the core of everything from OSs to 1K microcontroller firmware.
... lumbers along at 100MHz still.
Time we started working on that side of the hardware some more.
Sounds like someone got a good bucket sized serving from the gravy trough here to have this happen. The outcome is most likely going to be poor on efficiency and higher than "anticipated" on maintenance ( which will be no shock ), and the next bucket sized serving of gravy will be served up to "research" the issues further and facilitate someone's lifestyle.
Initially we were thinking it was a ball/pad issue, but we've found even with the jobs redone and bracing on the chassis to stiffen up the area, there's still a non-insignificant number of units coming back with the same issue (across multiple shops, not just one). Starting to look a bit more like an issue with either the actual chip itself or the PCB, not to say it definitely isn't a ball issue but it's not clear cut.
Either way, it's good to see Apple now admit the issue, though the $149 cost is still a bit of a cop-out ( no worries, people who have made a good income with the replacements will continue to do so for a while then ).
If it's using some sort of handshake likely it shouldn't need more than 100nA to get things started, a dedicated chip on the socket/device side, size clearly isn't an issue since they cram a couple in to the plug itself.
I'm speculating now too much.
As I understand it, it's only signal level power ( under 1mA) until the lanes are selected and switched for power. It may even be 1-wire (like Magsafe).
Sadly I cannot find any documents at this point to backup my statements.
AFAIK, the controller/management chip in the plug portion will not let full power through until it's confirmed the connection itself, part of the orientation smarts.
Similar to their magsafe as well (Macbook has to validate things before charger is told to deliver full power ).
*** I could be completely wrong *** ;)
Courage would be USB spec ditching their obsession with fragile tongue-on-equipment configuration and going with lightning type design. Not keen on everything Apple does but the lightning connector is good engineering against human incompetence. Empirically* micro / USB-C are a lot more prone to user-damage, hell people manage to break USB-A sockets.. how the hell!?
(*Phone & PC repair shop)
The lifetime environmental impact of lithium storage technology is less than that of alternatives. Our usage of lead-acid batteries is more toxic and we have a tremendous number of those being discarded each day, without even accounting for the impacts of fossil fuels involved in power generation and transport.
The mass penalty / structural workarounds, and the low incentive (given how few fatal crashes there are with air travel) will see this being pushed to the "amusing thought" pile and no real further. Much like massive parachutes from a long time ago ( some people use them on their smaller planes though ).
Out of all the major brands that I repair, iPhones are typicall the cheapest and easiest to repair and spare parts are plentiful ( though not Apple-blessed ), and contrary to people still thinking of the first iPhones, since the 3/3GS they've always used screws for assemblies; yes, there's some 2 sided tape as an addition to halt screen wiggles on the 4/4S but beyond that iPhones are very repairable. HTC, stuff that, throw it out, 2 sided tape, kapton tape, crazy clips. Samsung, used to be good with the S2, 3, 4 and similar era Notes, but as of the S5 it's a disaster and the replacement screens cost a small country. Nokia has some very nice to repair models and replacement screens are sensibly priced by few people seem to have them.
Now, if we talk about iPads/iPods, I absolutely agree, nightmares :(
Agreed. Went looking for some eInk solutions for a few projects a while back, ended up just giving up as there seems to be this great void between the accessible ( 2~2.5" max ) and the "Good luck buddy, no help for you!" 6"+ displays. Ever since eInk really captured the developer imagination, it feels like it's been some ludicrously guarded secret club to get your hands on a decent unit at a sane price.
Ideally I'd still love to see a reasonably fast refresh (10Hz) 13~15" eInk display.
At this point it still just waits for you to upgrade the iOS or factory-reset before it'll lock out with E53.
I do a fair number of these repairs each day, usually people who have smashed their screens so badly that they've lost the home button (or torn it).
These days we simply warn them of the impending doom and give them the option of how they'd like to proceed (repair and never upgrade, or get their data and ditch the phone).
The GPLv3 is the best thing for free software, because it forces everything to be free. The rest will die a slow death due to feature and user attrition.
Like that time Windows and OS X used to roam the earth.
I greatly appreciate the open source development world, writing, funding and using it every day, but it will inevitably live in the shadows of the commercial world from a consumer perspective for reasons that have nothing to do with the source code or licence.
Just wanted to jump on the bandwagon and agree with your view on this matter. It's already hard enough to get your foot in the door for establishing a presence, and time/effort is a rare commodity such that people will discard an option if it looks like it's going to be more work on top of simply learning how to integrate it in to their project.
Likely someone will end up writing a BSD-modified/Apache/MIT licenced implementation of this and *maybe* from that the standard might have more success in gaining a foothold (assuming there isn't cloud of subtly-broken implementations to poison the well), the downside for the original-standard though will be then that the majority of developers will be following someone else's developments.
All of my own FOSS projects have been set free in the world as BSD-modified.
I'm just getting on board with BlueCherryDVR, and I've made a mention of a couple of things that would be nice to have (all duly noted on their forum);
* Motion detection marking/denoting on continuous video record
* Adjustable brightness/contrast on the client
* Better motion detection algorithm ( the current one is excessively sensitive, even at minimal settings )
I concur too about the installation process. BCDVR was an absolute pleasure compared to the pains I endured to get ZM installed; BCDVR is also a lot more stable it seems, both server and remote client.
Well worth the money paid.
A shame you posted anonymously, would like to congratulate you on a technically correct and sensible post.
I really don't see the internet collapsing from him walking away. If it was a legitimate issue it'd be quickly picked up by another party, commercial or otherwise. I'd suggest he does just walk away from it. Even if a lot of money was pushed his way, I'm willing to speculate that he's burned out from all those hours (100/wk?) over the years and now wants to just set things up for a new person, step out, and close the door; been there, done that.
If we ceased having any NTP servers, then there's a more likely internet collapse scenario. The current NTP software seems to have been doing pretty good over the last couple of decades; or is there something that's progressively changing?
I appreciate that the guy has put a lot of work in to it, a lot of us (OSS developers) have and it's a passion more than anything else; if you get money out of it, it's a bonus, but one should never engage in it thinking there'll be any rewards other than seeing that the software itself grows and maybe a little bit of acknowledgement of what you've done. The OSS community can't get all up in arms with disgust when large corps use our software to help them progress, while not all corps give back to all projects, there's still a lot of stuff that is given back, or donated, even when not legally required.
The ethics of earning money off the back of OSS could be debated, but that's a whole different sphere. A lot of us already donate a lot of money already to various OSS projects as a nice feel-good gesture as well as a way to encourage further developments.
If people don't want megacorps making a "shit-tonne" of cash out of their work then they need to be forward thinking and put a clause in the licence to prevent this.
The software author has the power to control the licence. No one put a gun to their head and told them to release it free.
They should have gotten CSI on the job, need that zoom+enhance facility.
There's plenty of cases of electronics misbehaving due to exposure to strong light. Glass enveloped diodes (such as signal diodes) can be notorious for it, as can the black plastic encased units if the light is strong enough.
Small bare CoG (Chip on Glass) LCD panels will crash / hang when you use the flash on the camera taking photos of them in operation ( same reason, the controller die is exposed ).
It's not EM-pulse or xrays causing the problem, just good ole silicon junctions being exposed to intense light :)
You don't work with Windows development shops then!!
Right you are :D
Ignoring the actual Pi debate -
Darn those people who still use 68HC11 and 6502 controllers. You seem experienced enough to likely know yourself that if you've got a chip that's cheap enough not to ruin your BOM, that is available/in-production, does the job, has a solid toolchain, and coupled with years of development experience globally and in-house, then you don't just throw that all in the trash because something newer/faster/smaller/cheaper comes out.
Half the time I think a lot of people jump to the newest stuff because they don't like having their exclusivity eroded. Using older stuff makes sense when your product doesn't need cutting edge and you want to have a wealth of experience / dependability to draw from.
As for me, I'm still enjoying the AVR Tiny4/5/9/10 series, it's like the modern 555 ;)