How about using old hardware for longer and building optimized software that performs great even on old hardware?
This also offers more product flexibility from the same basic chassis. You can offer a "dumb" module for security-centric "cannot have unapproved devices on the network" markets, or a module that has specialized software or connectivity (i. e. a built-in KVM-over-IP client, or something bidirectional for hotels with internal cable and pay-per-view technologies)
Aside from the consumer benefit of "You can just snap in a new $100 module in 3 years and it will be snappy and up to date instead of scrapping a $600 set", this could be a good way to manage the ATSC 3 rollout. You can sell a 4K set today without an ATSC3 tuner, then the customer can add it as an "updated smart module" for $100 later once the format is live in their market.
In my case, I have an HD tv from 2006, it ain't smart, but it does tune to what ever port I want by default. I've got roku on there now, but in the past I've had cable boxes, consoles, even some rabbit ears.
"The customers must love this since they're buying 3x as many TVs! Keep em coming!"
Yes, and that's the problem.
Even if I look at my parents' TVs - all smart but they don't need or use that, they just watch cable.
https://www.cnet.com/tech/services-and-software/samsungs-war...
I'd like to see more power efficient dumb tvs. My favorite TV is a 65" led tv that sips power. At the same time, I've read that manufacturers providing data on their customers helps subsidize lower TV prices, and in that case adding apps likely doesn't incur that much more cost.
For a car, my guess is it's impossible to comply with modern emissions and safety regulations without ICs, not to mention the redesigning and retooling that would be required. I would suspect that these regulations have also basically evolved symbiotically with the industry to be a most for them, and they would have no interest in pushing to allow less complex cars.
For TVs and for cars, there are big revenue streams associated with things chips do, like serving ads and tracking what you do with your car, and well as making it impossible to maintain without a dealer. Companies would be very reluctant to shut this down.
None of this helps consumers, but I think that's where we are. Time to look at getting an old motorcycle maybe
Probably a healthy ability to reuse, repurpose, repair and recycle can be quite effective against the inability to just buy a new thing (regardless of whether the new thing is hi or lo tech)
I would have no issues going out and buying the latest macbook right now but basic other products are missing.
Like, if a washing machine or a car's fuel injector needs some chips, we should be able to reuse chips from older washing machines and older fuel injectors which we generally throw out because of a mechanical failure with all their electronics intact, but currently it seems that all these chips get just discarded, no one cares about them.
So if I design my washing machine around a particular chip, I could order a million of them for 5 cent each, or I would have to:
* somehow identify other models which have the chip
* find 1 million of them about to be discarded
* rip them open, desolder, collect these parts
* discard the rest of the machine
* do this for about 10 cents per washing machine
combined with the fact that washing machines usually last a decade and will be dying out over a time period spread out over 10-20 years after manufacturing time. How on earth would it be possible to pull off and by that time, these chips will be very obsolete / impossible to order new ones.
A big assumption that I'm making is that you would be extract the exact same components from many different devices, so you can build a washing machine with a component supply that's part new components and part 'reused' from all kinds of older washing machines, fridges or cars or smart toasters or whatever. This IMHO is true for generic electronic components (which are quite cheap but still add up in volume) but might not hold for chips - however, my initial argument probably was that if "chips-for-not-so-powerful-appliances" currently are structured to not be interchangeable, then perhaps they should be.
Once the OEM sold the board, they made all the money so they don't care about long term support.
A special class of theorem provers could be developed, proving that a program runs below a certain level of spacetime complexity.
This would entail a great increase in energy efficiency.
I also endorse holy information warfare against inefficient proof of work cryptocurrencies and a transition to efficient proof of stake.
Are you building in "release" mode? The debug builds can be 10x bigger.
cargo build --release
But yes, I have tried my own custom debug profile that turns on the optimisations to try to get the size down. The final binary is smaller, but `cargo build` still regularly leaves me with just kilobytes of space remaining, and then fails outright until I `cargo clean` and try again (which I think is build script related).
If you're building a docker image for example Rust is going to be smaller.
Sure, I could probably halve that by forking every dependency so they aren't duplicating versions, but that's a lot of work. (It's a shame Rust doesn't let you do conditional compilation based on dependency versions, or this would be a lot easier. As it is, we have to resort to the Semver trick: https://github.com/dtolnay/semver-trick/ — not that many people do that, so it's functionally useless.)
Take GanttProject as an example. It's 20.6MiB of files, plus the JVM. I challenge any of you to make a Rust version (with accessibility support in the GUI) that can open (something resembling) its XML files and draw some (vague graphical Proof of Concept) representation on the screen (with editable text fields), in less than 114+21=135 MiB of binary. And then tell me how, because I've been trying to do that kind of thing for over a year.
¹: I can get it down to around 8MiB with release mode, lto etc., but that significantly increases the build time and only about halves the weight of the intermediate build files.
How dare you claim a larger binary...
Let me guess; Go?
That would come at some kind of compile time or efficiency cost since you couldn’t anymore optimise for those but I’m sure that’s something one could opt for.
I don’t think binary size matters though. Storage is very cheap these days.
At least the prices are almost normal again, now that Chia's over.
You could also have self modifying code such that the size of the binary automatically changes as needed.
If you ship a lisp interpreter instead of rust, you can have the interpreter recode itself and any lisp files to a smaller size. You’d just implement a compression algorithm that preserves the functionality of the code compressed.
I think you could do that with rust too with a self compiling binary. It’ll require some real technical skill but if you hire a real hacker you can pull it off.
My cousin his solution for the competitive programming contest had something like that.
I do have a project a bit like that, but I'm not using Rust for it. I was trying to make my own language (like Rust, but more powerful and also smaller), but I'm probably just going to use a modified (safer) C.
If I were to write it in Rust, I'd have to compile it in the first place… and if I could do that easily, I would simply use Rust.
I would personally prefer a language model designed to emit x86 assembly, akin to Github copilot, but I understand that to be a minority viewpoint.
Do not rewrite software in Rust, because Rust is not an efficient language. It's a memory, and RAM hog, and it's unstable, with major breakers every release. Switching to Rust is not a thing for a profit seeking enterprise.
In practice, it's an n-fold downgrade from good C on performance.
Source? I was under the impression that Rust took an aggressive approach to back compat.
And I'm also not a proponent of rewriting in Rust for it's own sake, but the other commenter was suggesting it in place of Python, which would probably be a huge net gain in efficiency.
I know there exists a formally verified secure C compiler. Ideally you would have a similar compiler which guarantees low energy uses.
In my experience Rust already does a great job there but I’m happy to behold whatever evidence exists for C being more energy efficient.