I have used gkrellm since 1998 when my preferred wm was blackbox and playing MP3s in xmms was cool. Still run it today on Cinnamon. RIP Bill and thanks for the OSS contribution of a lifetime!
This works amazingly well for regulated software markets such as medical devices that need a lot of review/approval and traceability. Markdown is much more AI and script-friendly yet still layman readable. The workflow is significantly faster than industry standard tools like Windchill which are like git with a 1985 GUI in front of it.
I think that the nature of the thing that was needing to be implanted would determine whether it was easier and safer to use a traditional incision. Hip replacements for instance use a titanium joint. However, seeing as the bone that it is replacing was not made of titanium, somehow nature has found a way to make bone strong enough to do the job. There is an important sense in which nature 'builds things using 3D printing' and does it without needing incisions, so even if we do manage to master doing 3D printing under the skin the way we do it now to an extent where we can replace things that currently need materials that are not suited to under skin 3D printing...
I wonder if the origin of diediedie is a geek reference to the Usenet newsgroup alt.wesley.crusher.die.die.die, which was created not long after the premier of Star Trek: The Next Generation in 1987.
End of an era. I remember using them consistently in the mid- to late-90’s. Sad to see them go but change is the only constant in life. Goodbye old friend!
The article seems to suggest that turning to carbon capture is our best option currently. If that is the case then what is the best carbon capture technology we have right now and could it even make a dent?
I wonder if that's only true if we grow them then never cut them down. Because if the full lifecycle ends with combustion or another CO2 releasing process then it may offer no benefit.
We can turn them into charcoal and bury the coal. That's a pretty stable form of carbon storage and you get a bit of energy out of the process, e.g. in the form of wood-gas.
Why do I get the feeling this is repeating TCP features at the Message level? There must a protocol that can hide this exactly once need away. TCP doesn't create downloads, generally, that are bad and fail their checksum test, hence packets that make up the file are not duplicated.
Yes there is some duplication of TCP capability here.
The problem with relying on TCP for reliability is that its state is in memory, associated with a particular peer IP address, and acknowledgements passed back to the sender only indicate that the receiver has the data in local memory, not that the data has been processed.
A file download over TCP can fail, for example due to a network problem. Ensuring reliable delivery requires additional measures outside of TCP, such as retrying the download using a new connection.
In practice, this means that TCP is primarily useful for providing flow control and offering a streaming interface (no worry about packet sizes). Less so as a complete solution for transmission reliability.
How would you use TCP sockets to de-duplicate Kafka streams with a many-to-many communication pattern? Surely there is a valid scalability reason for why AWS IoT only provides "at least once" guarantees in their MQTT broker even when TCP is the underlying transport [1].
