HDMI has vastly more capacity in one direction. Modern ethernet is full duplex. If you replace HDMI 2.1 with ethernet, you first have to use twice the lanes, and half of them would then sit mostly unused.
You could use plain 100Gbps ethernet over copper, but even the cheapest transceiver options would be close to the cost of a cheap TV.
If you truly only use your phone for calls & text, why not buy a random Nokia? They are still available, and they have a MONTH of standby time now. You'll lose Sudoku, admittedly.
HDMI 2.1 gives you a usable Audio Return Channel! ARC gains enough bandwidth to actually make a surround sound setup worthwhile, it gains reliability since it isn't dependent on 1kHz CEC signalling with dubious vendor support, it gains more reliability because the wires it runs over are guaranteed to be properly shielded (little known fact: If you want to use ARC on HDMI 2.0 and below, buy a HDMI-ethernet-cable), it gains usefulness because it contains a lip-sync signal so you don't have to fiddle with audio delay settings to get video and audio to line up.
It will transform surround "receivers" completely. No longer will they need 7 HDMI inputs and go obsolete the moment the next HDMI standard comes out. No longer will they need complex remotes to try to get the right audio and video to the right outputs. No longer will they struggle with getting HDCP through from box to TV. You will simply plug the "receiver" into the TV with one HDMI cable, and the TV will do all that -- and the "receiver" will go back to its proper function and be a pure amplifier.
Overlapping windows don't work in any of the popular window managers anyway. Not in Windows, not in Mac OS, not in Gnome. You cannot have the window at the back be active so you can type in it, so you cannot use the contents of one window to do something in a different window.
The only solution is to avoid overlapping and tile instead, but again, Windows, Mac OS, and Gnome all fail spectacularly at that too, although they are beginning to at least try.
uBlock Origin has completely replaced RequestPolicy for me. Just enable advanced user mode, make "3rd-party" red, hit the save icon... Then whitelist just like with RequestPolicy, only faster and easier. It works as NoScript/YesScript on steroids as well.
Cookie AutoDelete has replaced Self Destructing Cookies.
It isn't a problem that different architectures have different ABIs. The problem was that different compilers, and even different versions of the same compiler, had different ABIs on the same architecture. Sometimes different enough to make linking fail, sometimes just different enough to make things break at runtime.
The C++ compiler is vastly better than it was 20 years ago, for one thing.
Also, you missed the ABI stability part. 20 years ago it would have been hard to support loadable modules compiled separately from the main kernel if the kernel was C++. Today, that would be much less of a problem.
Desert air is generally quite wet, in an absolute sense. In a relative sense it's low humidity, because warm air holds so much water. But cool it down to 5C and you'll see quite a lot of water precipitate out of it.
I did a quick Googling, and Phoenix apparently has quite high relative humidity in summer, whereas it is lower in spring and autumn. This is handy, as that means the water extraction has lots of humidity available right when solar panels are at peak output.
There's a dramatic difference in the amount of time children are allowed to spend unsupervised today compared to a generation ago. See The Overprotected Kid
It's great that they try to make more exciting playgrounds with less supervision, but it isn't the same as being allowed to spend hours with a friend in the park by the lake, without adults.
It definitely is worth remembering. I have never heard that side of the story. Do you have any references for this?
I have read stuff like this one:
"The CPU dispatch, coupled with optimizations, is designed to optimize performance across Intel and AMD processors to give the best results. This is clearly our goal and with one exception we believe we are there now. The one exception is that our 9.x compilers do not support SSE3 on AMD processors because of the timing of the release of AMD processors vs. our compiler (our compiler was developed before AMD supported SSE3). The future 10.x compilers, which enter beta this quarter and release around the middle of the year, will address this now that we've had time to tune and adjust to the new AMD processors."
which perpetually keeps performance for new AMD CPUs down until a new release of icc happens to come out, and everyone (right) recompiles their code. Since most benchmarking is done right when a CPU is released, and because a CPU is most expensive when it's first released, this puts AMD at a disadvantage.
It will also mean that you can hit cases where a newer AMD CPU runs code slower than the old one, simply because the icc compiler had the old one on the whitelist but not the new one at the time the code was compiled.
And many libraries I had to use were pre-compiled to generic specs rather than optimized.
Or they were compiled with icc, which adds check for whether the emitted code is running on an Intel chip, and jumps to generic unoptimized code if not. If it IS an Intel chip, the code does the usual flag checks to see which modern instructions are available and runs the appropriate code, but on non-Intel it doesn't get as far as checking flags.
Commonly used sed commands give the same results if you hand them to perl -p, and the regexp syntax is nicer in Perl. You lose a little bit on start up time, but if that bothers you, it's time to upgrade to a Raspberry Pi or something.
It is highly likely that there exists at least one set of values for S-Boxes for AES that would make the encryption trivially breakable. It is also highly likely that it would be possible to detect a datastream encrypted with that kind of broken AES. Those are not properties you want in an encryption algorithm.
Because the vast majority of files on most PCs are completely standard system or program files that no one really cares about getting encrypted. Fixing them is just a reinstall away, and the traditional ACL's are likely to prevent the wrong kind of access anyway.
The only stuff that's worth protecting is precisely the photo album and the documents folder and the genealogy database and similar. The system does not know which programs should be touching each directory, only the user knows. With Controlled Folder Access, the system can be told.
There is no such ability in Linux or *nix, since ACLs are solely based on uid and not the name of the executable with your uid.
Yes there is. There are even two in Linux, SELinux and AppArmor.
However, there is no easy-to-use GUI to administer it per-user, which means that you rely on the way-too-permissive default policy for most programs. This could have been done years ago technically, since SELinux and AppArmor are both quite old, but no one had the right idea apparently.
China dominates the market for rare earths, which are necessary for the high strength magnets that windmills need, and for the interesting material high efficiency solar panels need.
The majority of wind turbines do not use permanent magnets in their generators, and therefore they do not use rare earths. Only thin film solar cells use rare earths, and thin film is losing in the market at the moment.
Rare earths are a complete non-problem for the green industry.
Description: Body clock is unstable and the daily cycle extends as long as 36 hours unless reset. A proper quartz clock should be implemented.
Status: REJECTED
Comment: A more accurate body clock is not system critical. The timekeeping will be regularly reset by day/night cycle. If you stay away from light for a sufficiently long time for this problem to manifest, you are likely to be eaten by a grue.
Slashdot Mirror
HDMI has vastly more capacity in one direction. Modern ethernet is full duplex. If you replace HDMI 2.1 with ethernet, you first have to use twice the lanes, and half of them would then sit mostly unused.
You could use plain 100Gbps ethernet over copper, but even the cheapest transceiver options would be close to the cost of a cheap TV.
If you truly only use your phone for calls & text, why not buy a random Nokia? They are still available, and they have a MONTH of standby time now. You'll lose Sudoku, admittedly.
HDMI 2.1 gives you a usable Audio Return Channel! ARC gains enough bandwidth to actually make a surround sound setup worthwhile, it gains reliability since it isn't dependent on 1kHz CEC signalling with dubious vendor support, it gains more reliability because the wires it runs over are guaranteed to be properly shielded (little known fact: If you want to use ARC on HDMI 2.0 and below, buy a HDMI-ethernet-cable), it gains usefulness because it contains a lip-sync signal so you don't have to fiddle with audio delay settings to get video and audio to line up.
It will transform surround "receivers" completely. No longer will they need 7 HDMI inputs and go obsolete the moment the next HDMI standard comes out. No longer will they need complex remotes to try to get the right audio and video to the right outputs. No longer will they struggle with getting HDCP through from box to TV. You will simply plug the "receiver" into the TV with one HDMI cable, and the TV will do all that -- and the "receiver" will go back to its proper function and be a pure amplifier.
Overlapping windows don't work in any of the popular window managers anyway. Not in Windows, not in Mac OS, not in Gnome. You cannot have the window at the back be active so you can type in it, so you cannot use the contents of one window to do something in a different window.
The only solution is to avoid overlapping and tile instead, but again, Windows, Mac OS, and Gnome all fail spectacularly at that too, although they are beginning to at least try.
uBlock Origin has completely replaced RequestPolicy for me. Just enable advanced user mode, make "3rd-party" red, hit the save icon... Then whitelist just like with RequestPolicy, only faster and easier. It works as NoScript/YesScript on steroids as well.
Cookie AutoDelete has replaced Self Destructing Cookies.
Not only does it do NoScript better, it also does RequestPolicy better!
Thank you so much, I had no idea that uBlock Origin could do those things!
It isn't a problem that different architectures have different ABIs. The problem was that different compilers, and even different versions of the same compiler, had different ABIs on the same architecture. Sometimes different enough to make linking fail, sometimes just different enough to make things break at runtime.
The C++ compiler is vastly better than it was 20 years ago, for one thing.
Also, you missed the ABI stability part. 20 years ago it would have been hard to support loadable modules compiled separately from the main kernel if the kernel was C++. Today, that would be much less of a problem.
Showers with built-in water recycling exist commercially already. They are just expensive. Then you can pretty much have as many showers as you want.
Consumes, yes. The water is turned into steam.
It is exactly Sveasoft.
I just checked, Arizona is landlocked. If desalination was the plan, surely it would make sense to move the project closer to the ocean?
Desert air is generally quite wet, in an absolute sense. In a relative sense it's low humidity, because warm air holds so much water. But cool it down to 5C and you'll see quite a lot of water precipitate out of it.
I did a quick Googling, and Phoenix apparently has quite high relative humidity in summer, whereas it is lower in spring and autumn. This is handy, as that means the water extraction has lots of humidity available right when solar panels are at peak output.
I forgot to add the crucial "at 5-7 years old"
There's a dramatic difference in the amount of time children are allowed to spend unsupervised today compared to a generation ago. See The Overprotected Kid
It's great that they try to make more exciting playgrounds with less supervision, but it isn't the same as being allowed to spend hours with a friend in the park by the lake, without adults.
It definitely is worth remembering. I have never heard that side of the story. Do you have any references for this?
I have read stuff like this one:
"The CPU dispatch, coupled with optimizations, is designed to optimize performance across Intel and AMD processors to give the best results. This is clearly our goal and with one exception we believe we are there now. The one exception is that our 9.x compilers do not support SSE3 on AMD processors because of the timing of the release of AMD processors vs. our compiler (our compiler was developed before AMD supported SSE3). The future 10.x compilers, which enter beta this quarter and release around the middle of the year, will address this now that we've had time to tune and adjust to the new AMD processors."
which perpetually keeps performance for new AMD CPUs down until a new release of icc happens to come out, and everyone (right) recompiles their code. Since most benchmarking is done right when a CPU is released, and because a CPU is most expensive when it's first released, this puts AMD at a disadvantage.
It will also mean that you can hit cases where a newer AMD CPU runs code slower than the old one, simply because the icc compiler had the old one on the whitelist but not the new one at the time the code was compiled.
And many libraries I had to use were pre-compiled to generic specs rather than optimized.
Or they were compiled with icc, which adds check for whether the emitted code is running on an Intel chip, and jumps to generic unoptimized code if not. If it IS an Intel chip, the code does the usual flag checks to see which modern instructions are available and runs the appropriate code, but on non-Intel it doesn't get as far as checking flags.
In perl the JIT compiler is named perl... If you want ahead-of-time-compilation you probably want perlcc -O.
Commonly used sed commands give the same results if you hand them to perl -p, and the regexp syntax is nicer in Perl. You lose a little bit on start up time, but if that bothers you, it's time to upgrade to a Raspberry Pi or something.
It is highly likely that there exists at least one set of values for S-Boxes for AES that would make the encryption trivially breakable. It is also highly likely that it would be possible to detect a datastream encrypted with that kind of broken AES. Those are not properties you want in an encryption algorithm.
Because the vast majority of files on most PCs are completely standard system or program files that no one really cares about getting encrypted. Fixing them is just a reinstall away, and the traditional ACL's are likely to prevent the wrong kind of access anyway.
The only stuff that's worth protecting is precisely the photo album and the documents folder and the genealogy database and similar. The system does not know which programs should be touching each directory, only the user knows. With Controlled Folder Access, the system can be told.
You trust wine as a sandbox? That is... courageous.
There is no such ability in Linux or *nix, since ACLs are solely based on uid and not the name of the executable with your uid.
Yes there is. There are even two in Linux, SELinux and AppArmor.
However, there is no easy-to-use GUI to administer it per-user, which means that you rely on the way-too-permissive default policy for most programs. This could have been done years ago technically, since SELinux and AppArmor are both quite old, but no one had the right idea apparently.
China dominates the market for rare earths, which are necessary for the high strength magnets that windmills need, and for the interesting material high efficiency solar panels need.
The majority of wind turbines do not use permanent magnets in their generators, and therefore they do not use rare earths. Only thin film solar cells use rare earths, and thin film is losing in the market at the moment.
Rare earths are a complete non-problem for the green industry.
Description:
Body clock is unstable and the daily cycle extends as long as 36 hours unless reset. A proper quartz clock should be implemented.
Status:
REJECTED
Comment:
A more accurate body clock is not system critical. The timekeeping will be regularly reset by day/night cycle. If you stay away from light for a sufficiently long time for this problem to manifest, you are likely to be eaten by a grue.