Oh, when the plastic pieces turn smaller than microplastics they become nanoplastics which have a whole lot of other issues for health and the environment. You would not want to inhale it.
Wear-down of car tyres is known as a significant cause of micro and nano-plastics in the environment. Tyres are usually made of a mix of natural rubber and synthetic rubber - and synthetic rubbers are also plastics, more or less.
Another significant health issue in colder climates is that studded snow tyres wear down paved road surfaces into hazardous airborne dust. Many cities in Nordic countries have therefore banned the use of studded tyres in city centres and/or on their most well-trafficked streets.
Instead of abandoning ABS completely, I think it is about time to consider expanding the recycling of existing ABS to include not just packaging but also products themselves. Would that be feasible?
Everyone of us has quite a large number of items made from ABS. It is very common in electronics for instance. Just looking around me, my keyboard, mouse and monitor bezel in front of me are made of ABS. Electronics should be recycled, and their enclosures are probably recycled with the rest but not all plastic enclosures have a resin identification code so that the type of plastic could be determined easily when recycled. One challenge could be that ABS comes in many different variations, with varying proprtions of A (acrylonitrile), B (butadiene) and S (polystyrene), plus additives for UV-resistance or flame retardants.
ABS is such a versatile, wonderful material. I think we should treat it as such.
He who makes other people work for him, so that he does not have to work himself lives longer. He who does not need to care about how to earn the next pay check does not need to stress about it or exert himself. Yes. Of course. That's not rocket science.
That's why statistics say that members of high-income households are more healthy --- even in countries with universal health care where access to health care is not a question of wealth.
Monolithic kernels had a syscall performance advantage... before the Meltdown patches were applied.
The security advantage of microkernels is that you could reduce the attack surface by making your Trusted Computing Base as small as possible. The seL4 microkernel has been formally proven safe. That is possible because it is small enough, but it still took years. You can't do that with something as Linux.
The locus in OS research seems to have moved on towards multikernels for better performance on systems with many cores. A multikernel is basically about having a separate microkernel on each core, each core's kernel chosen to be the best available for the tasks that run on it. Linus, on the other hand, does not like CPUs with many cores...
I think Google's transition from Linux to the Zircon microkernel (Fuchsia) is still quite some time in the future.
I believe that Google's reason for Fuchsia is mostly to do with Linux' security model being a bad match for Android. In Android, every app is running as its own Linux user. In Zircon, there is instead the "Job" abstraction that can contain processes, and access rights are based on capabilities that the mainline Linux kernel does not have. ("Posix Capabilities" are not capabilities:-P)
For this reason Chrome/Chromium is more or less sandboxed on every platform it runs --- and I say "more or less" because it has to be in a different way on each platform to take advantage of what each platform provides. On some platforms such as MS Windows, the code for making it run somewhat securely can be quite convoluted.
The instances where goto is useful can often be boiled down to a few different cases. IMHO it would be better to have specific language support for those cases than a generic statement. Having a generic goto (or even only a breaklabel-statement) would encourage it to be used for things that it wasn't intended for, and such code would not be as readable.
* Breaking out of nested loops. Something like breaklabel or multibreaknumber. * Clause after a loop has reached its end and not broken. Python reuses else for this. * Error handling: A type of exception handling. It could be simplified by using labels instead of throwing and catching objects of specific types.
The word "hack" applied to computers and electronics is an analogy to using a hacksaw to a table leg, hence the name. Therefore, it is indeed about a quick and simple solution to a problem.
If it should be considered elegant or not to cut the table's other leg shorter to make it less wobbly... that's anyone's opinion.
Oh, there are reversible Micro B connectors out there. They work with existing sockets. It was introduced in 2015 but there are multiple options now and cables are widely available. (If that is not what you meant, there is the On-The-Go (OTG) standard, so Micro-USB could be used as a host port as well.)
Other than power delivery I find the problem with USB Micro B be that it is not compulsory for sockets to have through-hole mounts, and therefore those that don't are more fragile. USB Type C rectified that. On the other hand, USB C has many teeny tiny connectors inside the plug and socket, and I wonder if not those would break first and what then would happen.
Oh. I really hate infinite scroll. The "infinite scroll" has only one valid use IMHO: When you are displaying a timeline, looking back from the present. That is what it was invented for in the first place.
Another thing I hate is links that are not links but buttons that act like links --- but only when left-clicked. Those can't be opened in a new tab or window. Combined with infinite scroll, that is just hell.
Or about about when you click on a "link", and the new "page" occupies the entire browser window... but it wasn't a page but a popup in disguise. You press Back to get back to where you were but instead you get out of the site and have to press Forward again and you loose your navigation in the "infinite scroll" because the context is not retained in the browser.
Or how about pages with a button that says "More", and it replaced the items in a list walking forward in a collection and scrolled automatically to the top of the list... thus looking like an infinite scroll even though it isn't.
Oh, and buttons that don't appear until you hover. How many times have you not clicked on those accidentally... I don't want to think about how those sites work on tablets or on convertibles where you have both mouse and touch.
Yeah, but the SoCs with many and faster ARM cores are often paired with FPGAs that are overkill for emulating the Amiga chipset and would therefore be too expensive to compete with MiST, Vampire or a Raspberry Pi.
And then the key part: giving the FPGA its own "Chip RAM", with access from the emulator on the ARM core.
Instead of a 100 MHz CPU in FPGA running against vintage graphics and sound chips, I would much rather like to see the vintage graphics and sound chips in FPGA but the CPU being emulated, with JIT-compilation running on a fast modern ARM multi-core chip.
That would be a really powerful Amiga, and you would be able to run other things (such as OS:es and emulation cores) on it as well.
However, I have not found any FPGA board that has had any good interlink with any powerful ARM chip. The ones I have seen (including MiST) have used the CPU for loading cores onto the FPGA and not much more. The FPGA would need to provide an interface from the CPU to the machine's "Chip RAM" and that might be a bit too unusual?
It would be an even faster phone if the voice of the person you were talking to was less garbled.
Oh, when the plastic pieces turn smaller than microplastics they become nanoplastics which have a whole lot of other issues for health and the environment. You would not want to inhale it.
Wear-down of car tyres is known as a significant cause of micro and nano-plastics in the environment. Tyres are usually made of a mix of natural rubber and synthetic rubber - and synthetic rubbers are also plastics, more or less.
Another significant health issue in colder climates is that studded snow tyres wear down paved road surfaces into hazardous airborne dust. Many cities in Nordic countries have therefore banned the use of studded tyres in city centres and/or on their most well-trafficked streets.
clang/LLVM had been developed in tandem with, practically for a project for making C code safer in the first place: SAFECode.
Instead of abandoning ABS completely, I think it is about time to consider expanding the recycling of existing ABS to include not just packaging but also products themselves. Would that be feasible?
Everyone of us has quite a large number of items made from ABS. It is very common in electronics for instance. Just looking around me, my keyboard, mouse and monitor bezel in front of me are made of ABS.
Electronics should be recycled, and their enclosures are probably recycled with the rest but not all plastic enclosures have a resin identification code so that the type of plastic could be determined easily when recycled.
One challenge could be that ABS comes in many different variations, with varying proprtions of A (acrylonitrile), B (butadiene) and S (polystyrene), plus additives for UV-resistance or flame retardants.
ABS is such a versatile, wonderful material. I think we should treat it as such.
I come here for the Apple jokes in the comment section...
Turn signals are not interpreted only by other motorists on the road but also by pedestrians.
This is very useful on parking lots, for instance.
Meh. I'm tired. Sorry. Please mode the above post "Redundant" or "Off-topic."
He who makes other people work for him, so that he does not have to work himself lives longer. He who does not need to care about how to earn the next pay check does not need to stress about it or exert himself.
Yes. Of course. That's not rocket science.
That's why statistics say that members of high-income households are more healthy --- even in countries with universal health care where access to health care is not a question of wealth.
Ten years for forgetting my pin number. I have done that.
They might just as well lock everyone up in advance, just in case.
Monolithic kernels had a syscall performance advantage ... before the Meltdown patches were applied.
The security advantage of microkernels is that you could reduce the attack surface by making your Trusted Computing Base as small as possible.
The seL4 microkernel has been formally proven safe. That is possible because it is small enough, but it still took years. You can't do that with something as Linux.
The locus in OS research seems to have moved on towards multikernels for better performance on systems with many cores. A multikernel is basically about having a separate microkernel on each core, each core's kernel chosen to be the best available for the tasks that run on it. ...
Linus, on the other hand, does not like CPUs with many cores
I think Google's transition from Linux to the Zircon microkernel (Fuchsia) is still quite some time in the future.
I believe that Google's reason for Fuchsia is mostly to do with Linux' security model being a bad match for Android. In Android, every app is running as its own Linux user. In Zircon, there is instead the "Job" abstraction that can contain processes, and access rights are based on capabilities that the mainline Linux kernel does not have. ("Posix Capabilities" are not capabilities :-P)
Actually, GNU/Hurd has seen relatively much development only in recent years and you can install and run it in command-line mode.
Userland GNU/Hurd is the same as GNU/Linux, so your statement does not really hold.
For this reason Chrome/Chromium is more or less sandboxed on every platform it runs --- and I say "more or less" because it has to be in a different way on each platform to take advantage of what each platform provides.
On some platforms such as MS Windows, the code for making it run somewhat securely can be quite convoluted.
No. Because the Space Force is not interstellar.
The instances where goto is useful can often be boiled down to a few different cases.
IMHO it would be better to have specific language support for those cases than a generic statement. Having a generic goto (or even only a break label-statement) would encourage it to be used for things that it wasn't intended for, and such code would not be as readable.
* Breaking out of nested loops. Something like break label or multibreak number.
* Clause after a loop has reached its end and not broken. Python reuses else for this.
* Error handling: A type of exception handling. It could be simplified by using labels instead of throwing and catching objects of specific types.
Who the hell approved this story in the current form?
The word "hack" applied to computers and electronics is an analogy to using a hacksaw to a table leg, hence the name.
Therefore, it is indeed about a quick and simple solution to a problem.
If it should be considered elegant or not to cut the table's other leg shorter to make it less wobbly ... that's anyone's opinion.
Oh, there are reversible Micro B connectors out there. They work with existing sockets. It was introduced in 2015 but there are multiple options now and cables are widely available.
(If that is not what you meant, there is the On-The-Go (OTG) standard, so Micro-USB could be used as a host port as well.)
Other than power delivery I find the problem with USB Micro B be that it is not compulsory for sockets to have through-hole mounts, and therefore those that don't are more fragile.
USB Type C rectified that.
On the other hand, USB C has many teeny tiny connectors inside the plug and socket, and I wonder if not those would break first and what then would happen.
Oh. I really hate infinite scroll.
The "infinite scroll" has only one valid use IMHO: When you are displaying a timeline, looking back from the present. That is what it was invented for in the first place.
Another thing I hate is links that are not links but buttons that act like links --- but only when left-clicked. Those can't be opened in a new tab or window.
Combined with infinite scroll, that is just hell.
Or about about when you click on a "link", and the new "page" occupies the entire browser window ... but it wasn't a page but a popup in disguise. You press Back to get back to where you were but instead you get out of the site and have to press Forward again and you loose your navigation in the "infinite scroll" because the context is not retained in the browser.
Or how about pages with a button that says "More", and it replaced the items in a list walking forward in a collection and scrolled automatically to the top of the list ... thus looking like an infinite scroll even though it isn't.
Oh, and buttons that don't appear until you hover. How many times have you not clicked on those accidentally...
I don't want to think about how those sites work on tablets or on convertibles where you have both mouse and touch.
I pulled quite a few all-nighters with my computer when I was a teenager, before I even had dial-up Internet.
Of course a lot of time was spent on dial-up BBS:es, not to mention the telephone bills ...
Your EeePC cost half as much, had USB ports and in most of them you could upgrade the memory and harddrive/SSD.
Yeah, but the SoCs with many and faster ARM cores are often paired with FPGAs that are overkill for emulating the Amiga chipset and would therefore be too expensive to compete with MiST, Vampire or a Raspberry Pi.
And then the key part: giving the FPGA its own "Chip RAM", with access from the emulator on the ARM core.
From your username and your like of Atari... you are from Poland, right?
I found recently that the Atari 8-bit is very popular there for some reason.
Replying to an argument rooted in science with an argument rooted in ideology.
How very enlightened of you.
Instead of a 100 MHz CPU in FPGA running against vintage graphics and sound chips, I would much rather like to see the vintage graphics and sound chips in FPGA but the CPU being emulated, with JIT-compilation running on a fast modern ARM multi-core chip.
That would be a really powerful Amiga, and you would be able to run other things (such as OS:es and emulation cores) on it as well.
However, I have not found any FPGA board that has had any good interlink with any powerful ARM chip. The ones I have seen (including MiST) have used the CPU for loading cores onto the FPGA and not much more. The FPGA would need to provide an interface from the CPU to the machine's "Chip RAM" and that might be a bit too unusual?