We had a guy like him in our group and he did cause us a lot of trouble. He made the female co-workers uncomfortable and we had several people quit because of him. He'd make a lot of sexist comments behind their backs as well. There was a big sigh of relief when he left because of how uncomfortable he made people feel. He was endlessly quoting Breitbart and Infowars like it was the gospel truth. When he threw out resumes with Muslim names I thought he should have been fired for that, instead, they just made it so he wasn't allowed to interview anyone.
It has nothing to do with SJWs and more to do with destroying the cohesiveness of a team and making other team members uncomfortable by making disparaging comments about them due to their gender.
That seems to fit my experience as well. We had one big Trump supporter in our group who would quote Inforwars and Brietbart at us endlessly like it was the gospel truth. He got in trouble because he refused to even look at a resume from someone with a Muslim name (he is Jewish). The women in the group hated him for the way he treated them and the remarks he made about them. He couldn't exit fast enough. My group has a fair number of good female engineers.
And yet the state still has to cover the cost of things like unemployment, sewage treatment, roads and all the other things that Foxconn and their employees will make use of but won't pay for, since there will be no payroll taxes. The state will have to pay for unemployment when the jobs are automated away, and Illinois will clean up since many of the people will just commute from there over the border. Foxconn now gets the city and state to pay for maintaining all the roads for the workers without paying a dime. Similarly, there are all the other services Foxconn will use and again not have to pay for and the income taxes on the employees won't cover it. The employees won't be paid a huge amount either with an average wage of $53K. The payback time is only the best case scenario. The area already has very low unemployment with companies already having a hard time filling positions. The unemployment rate is 3.3%. It would make a lot more sense for Wisconsin to encourage the plant to be built in an area where there is high unemployment or underemployment, not a place where there is already full employment.
It most certainly IS a real shutter. Both of my DSLRs have real shutters and all of my past DSLRs have had real shutters just like the film cameras that preceded them. The shutter sits behind the mirror.
They most certainly do. Both of my DSLRs have real shutters. In fact, for long exposure mode, it takes two pictures, one with the shutter open and another with it closed to help remove noise from hot pixels. Many point and shoots use electronic shutters. What I miss is the electronic shutters of CCDs which activated the entire sensor at once so you don't get this rolling shutter crap from a lot of CMOS sensors. Unfortunately, CCD sensors suck at just about everything else compared to CMOS.
There are many situations where a phone camera will fall far short. A camera phone is fine if you can live with only one or two focal lengths and limited lighting conditions and don't care about controlling things like shutter speed, bokeh, noise, etc. A DSLR certainly makes things a lot easier. Many point and shoot cameras get in my way and actually prevent me from doing what I want to do. The last one I used went out of its way to prevent me from having any manual control.
One other big advantage with a good DSLR is the controls. With my DSLR I can instantly change many different settings without hunting through menus. I've found that many point and shoot cameras have done away with a lot of the controls I like, instead only having automatic modes like "pet mode" and crap like that. I want to be able to quickly adjust the exposure to how I want it, choosing shutter speed, aperture, ISO, white balance, etc. I also have a lot more control over the lighting by being able to adjust my flashes as needed. I can make most of these changes without ever having to take my eye off of my subject.
Having a variety of lenses is also a big benefit. In a couple of weeks, I'm driving up to photograph the eclipse and will be connecting the body of my camera to an 8" telescope which basically becomes a 2000mm lens which works great for this. Rather than have people peek through the eye piece I'm bringing an LCD monitor and an HDMI cable hooked up to my camera to make it easier for others to view it. On my other camera with an APS-C sensor, I'll use my 300mm zoom lens with a solar filter. Since I have a tracking tripod I can just use that for the camera with my 300mm lens.
I also can do a lot of things that are difficult or even impossible to do post processing, such as slapping on a circular polarizer filter to darken the sky or reduce reflections.
The best camera, however, is the camera you have. I've taken a fair number of photos with my Pixel camera and for quick snaps and panoramas it does a decent job, but it doesn't come close to a DSLR with my default zoom lens. For my Nikon D800 I typically use a 24-70mm f2.8 lens and my D300 I have a 17-55mm f2.8 for most of my photography. They're tack sharp. For low light stuff, I'll throw on a prime like my F1.4 50mm. I also love shooting shallow depth of field which is easy with a fast lens, especially with a full frame camera. The other thing with DSLRs is it isn't the body that's the important part, it's the glass. Camera bodies come and go but the lenses hold their value and old lenses typically work great with new bodies. Most of my lenses even work on old SLR cameras and lenses from the SLR days work on my DSLR.
Let's face it, a cell phone's camera and lens is probably no more than $10, maybe $20, maybe a bit more for a high end one.
Last Friday I got an Amazon Echo Dot and Google Home to play with and I have used Google's Android assistant for some time. My guess is that Samsung will have a lot of catching up to do. In playing with both Google and Amazon I have found that in most cases Google Home is superior to the Echo even though the Echo has been available longer. The home automation just seems to work better with Google Home. I can say "Hey Google, turn off all the lights" from my bed and all the lights in my house are turned off. Or "Hey Google, what lights are on?" to see if someone left one on. Asking for basic information Google Home is usually spot on. Amazon Echo either doesn't know or gives less precise data when it does. Both systems support my home automation, thermostat and even my car (I can monitor charging, turn on the AC, etc. of my car via both).
For search, Google is king. Alexa doesn't come anywhere close. I still need a chance to play more with the Chromecast integration and it sounds like more is coming. For example, Google Home will not play music via the video Chromecast yet. The best advantage with GH is that it works seamlessly with my phone and tablet so I just need to say "OK Google" and it works. I don't like the idea of purchasing stuff via voice and I still have a lot more to explore.
If I had that sort of overhead my software would not exist or work. Some of it has very tight memory constraints and besides, there would be no support for all the things one might expect. There's no heap, only a small stack available. Rust just isn't an option. Also, the entire toolchain is gcc, which precludes the use of Rust since Rust currently requires LLVM which does not have any of the optimizations that are required in order to allow the software to fit in the size constraints. Rust buys nothing but headaches. Many of Rust 'features' become hindrances, requiring a lot more overhead in terms of code space and efficiency. Remember, these are conditions completely different than some user-space application running on the command line.
Another killer for embedded use is the lack of the volatile keyword. This is essential, and "atomics" don't cut it. The lack of "volatile" pointers is a major killer, especially for dealing with hardware descriptors and memory mapped registers.
Rust is not all that portable. Rust is tied to LLVM. There are a lot more platforms supported by, say, GCC than LLVM. For example, I'm working on some Arduino and Xtensa based stuff at the moment. No Rust support but C and C++ are both supported. It's also trivial to link between C and assembly or for that matter C and just about any other language. I mix C and assembly all the time in the work that I do. I don't need any overhead of garbage collection, bounds checking, etc. either. The C calling ABI is very well documented and supported on all but the lowest end microcontrollers. If I write a library in C, it can be called from virtually any language. If I write a language in Rust, i doubt that would be the case. The C runtime library is pretty trivial. I've written bootloaders with only a page of assembly before calling the main function. By bootloader I'm referring to a true bootloader, code that is the first code executed when a CPU comes out of reset, not something called by the BIOS but code that will at some point load the BIOS.
I agree. If Firefox or Thunderbird is anything to go by I'd stay far away. I used Thunderbird for years until very recently but its performance is unusably bad. On my quad core xeon workstation it's almost impossible to write email because the editor freezes so frequently, often for seconds at a time. In the process it drops characters so I can't even type ahead. I suspect it's due to its single threaded nature and I'm dealing with several IMAP accounts with a LOT of emails. I recently switched over to KMail which seems to work far more smoothly. On top of that, Thunderbird is a huge memory pig. I gave up on Firefox ages ago and switched to Chrome due to horrible performance with single-threaded Javascript and the fact that it leaked memory like crazy for years. I also blame Mozilla for killing off MNG which is why we so often are STILL stuck with gif, which is a horrible format for most of the animations I see.
Rust has its place but it isn't going to replace C any time soon. There are other languages that also make the same claims, i.e. Go, Swift, D, etc.
One thing about C is it is supported on virtually everything except the micros where only assembly or some oddball language is the only thing supported (I used a processor that ran a pattern matching functional programming language at the hardware level once). There are plenty of other languages that are better than C in many cases, but one thing with C is you don't need to worry about libraries having weird interactions with other languages. C bindings are ubiquitous and very well understood and supported. C++ apps can easily link to and call C libraries but the other direction often requires some glue logic. Most languages can link against C code whereas the opposite is often not true. C has very minimal underlying requirements. I have written numerous bootloaders in C which require only around a page (or less) of assembly code. By boot loader, I'm talking about with no BIOS underneath for embedded systems. Cross compiling is well supported as well and I frequently am cross compiling for MIPS or AARCH64 with compilers that are tuned to the specific chips they're targeting.
I'm playing with an ESP32 device right now which has two Xtensia cores in it. No Rust support but C and C++ are both supported. There's no underlying operating system. Similarly, one doesn't run Rust on Arduino platforms. Rust is tied almost exclusively to LLVM. There is no GCC support for Rust so there are plenty of platforms where Rust just isn't supported.
C and C++ are supported by many toolchains, both open source and proprietary. Rust is not.
Rust developers seem to think that Rust is the answer to everything when it is not. I recall getting into an argument with a Rust developer over the fact that I refuse to even look at Rust. I write low-level boot loaders with a mixture of C and some assembly language for embedded systems where size can be a real premium and I'm working close to the hardware where things like pointer checking would cause a lot of problems and I don't have space for all the extra overhead (i.e. bounds checking, garbage collection, etc.) when every byte of space counts. In addition, I am cross compiling using the GCC toolchain optimized and tuned for the particular chips I'm working with (MIPS64 and ARMv8). Rust would be a big pain in the butt for the stuff I deal with where I frequently rely on the features of C that are considered "unsafe" like typcasting pointers to specific memory addresses, allocating memory without garbage collection, etc. While you can do those things with Rust, all of those Rust features get in the way and require language overhead of a run-time library (I don't have the C run-time library in many cases). Then there's the fact that I know the C cross compiler is very well supported and optimized for our architecture (we have a team of compiler people where I work). On the side I'm playing with an ESP32 (Xtensa CPU cores) device and Rust is not supported. C and C++ are supported, on the other hand. I was just looking at TLS support for a project I'm planning on the ESP32 and found an open-source cross-platform C library for it that works within its constraints, considering the fact that it does not have a real operating system. As far as I can tell, Rust is not supported at all on the ESP32 since LLVM is not supported (but gcc is).
I can throw C at basically anything. In some of the MIPS bootloaders I've written I need only about a page of assembly code before jumping to C code. There's no way I could do that with Rust.
No language is good at everything. C has a very long track record and is supported by virtually every CPU out there other than some extremely limited micros that only support assembly language or other oddball languages. (I once worked with a processor that executed a functional programming pattern-matching language in hardware that was incapable of running C). The FPL was basically assembly to this processor.
I don't know Rust other than what I've read about the language and I'm sure it has its place. One other thing to realize is that a lot of languages come and go.
Look at Java, for example. At one point there was a huge rush to support Java for everything but that has died down. One doesn't see many Java apps any more and I must say that it's always a major pain in the butt every time I need to use one now (especially since Oracle's Java RPM is broken and won't install without a lot of hacking... they screwed up the alternatives settings). Also, Oracle refuses to upgrade their Java plug-in to work with Chrome and modern plug-in interfaces.
C and C++ are very well established and have long track records and they are not controlled or dominated by any one company or group. I've also lost a lot of respect for Mozilla. The Firefox browser has been a disaster for a long time, and don't get me started on how bad Thunderbird is... Thunderbird on all of my systems is so slow I can barely type to compose an email due to its horrible single-threaded nature. I dumped Firefox for the most part a long time ago and haven't looked back. The horrible memory leaks and bad single-threaded Javascript killed it for me and they ignored the major problems for years. There's a reason Apple adopted KHTML for Webkit.
There are plenty of other similar programming languages, i.e. D, Go, Swift, etc. Only the test of time will prove its success. C and C++ have withstood the test of time, warts and all.
I tend to do a lot of builds and can definitely benefit from something like this since I can take advantage of all of those cores. There are numerous workloads that can certainly take advantage of more cores. Even at home, they come in handy when batch processing photos.
Bats are opportunistic feeders and while mosquitoes are a part of their diet they aren't a major part compared to larger insects. The elimination of disease carrying mosquitoes will not have a major impact on bats. They are not the main food source by any means and only make up a small part of their diet.
"studies of bats in the wild have shown that they consume mostly beetles, wasps, moths, and these same studies have shown that mosquitoes make up less than 1 percent of their total diet."
Compared to the next oldest car company they are. The last time an American car maker went public was Ford in 1956. The last time a major US car company that still exists was founded was 1925 (Chrysler), though some may argue about the fact that Chrysler is now owned by Fiat (founded in 1899). By comparison, Tesla is certainly a start-up.
With hardware acceleration AV1 is not that battery intensive. Just about everyone is adopting AV1 except Apple. What makes a big difference is if the underlying hardware supports offloading AV1 encoding and decoding. All of the major hardware vendors will support AV1, including Intel, AMD, ARM and Nvidia. Apple is the lone holdout. Most web browsers except Safari support AV1 which builds on VP9. VP9 is also not supported by Apple.
It's probably pretty good with the right tires. The weight is all down low and it has a massive amount of low-end torque, not to mention very good traction control. It also has a very stiff body. While it may not have as high of clearance as some other cars (though with active suspension it can raise itself), other than that it should do quite well. http://insideevs.com/tesla-mod...
Years ago I worked on an ipsec product and was successful getting it to work. The problem is that since then the complexity has increased significantly. Making matters worse is that different commercial products do it differently. Linux to linux is one thing, because one can easily verify that all of the appropriate settings are the same. Linux to a commercial box, on the other hand, is a big problem.
For example, my home router, a Mikrotik box, has a bazillion options for ipsec but trying to figure out the correct combination to make it actually work is a major pain in the butt. IPSec's problem is that it is so complex, and when it comes to commercial products they often offer a driver for Windows and maybe Mac but when it comes to Linux you're often out of luck when it comes to connecting to them, though they may offer some Java in the browser (ugh) thing.
Last night I tried to get pptp to work with our corporate VPN and it failed miserably. I ran Wireshark to figure out what the problem is and the Linux PPP stack just can't handle the options that it was being sent (bug opened on pppd). Next I tried to connect to my home firewall VPN which used to work and again this failed miserably because the Linux PPP stack refused to turn off the async char map negotiation (which isn't used for PPTP).
I've also struggled to get ipsec in any form to work (no success) nor have I been able to get openvpn to work, requiring all the generation of certs and whatnot. PPTP, despite being quite insecure, at least used to work before the modern PPP brokeness.
The problem with VPNs is that the solutions are overly complicated with a bazillion different options.
IPSec + L2TP!?!?! This is insane. PPTP is just plain broken as well.
I want something as simple as how PPTP used to work but without all the broken security (i.e. MD5 password hashes) and get rid of PPP.
Slashdot Mirror
We had a guy like him in our group and he did cause us a lot of trouble. He made the female co-workers uncomfortable and we had several people quit because of him. He'd make a lot of sexist comments behind their backs as well. There was a big sigh of relief when he left because of how uncomfortable he made people feel. He was endlessly quoting Breitbart and Infowars like it was the gospel truth. When he threw out resumes with Muslim names I thought he should have been fired for that, instead, they just made it so he wasn't allowed to interview anyone.
It has nothing to do with SJWs and more to do with destroying the cohesiveness of a team and making other team members uncomfortable by making disparaging comments about them due to their gender.
That seems to fit my experience as well. We had one big Trump supporter in our group who would quote Inforwars and Brietbart at us endlessly like it was the gospel truth. He got in trouble because he refused to even look at a resume from someone with a Muslim name (he is Jewish). The women in the group hated him for the way he treated them and the remarks he made about them. He couldn't exit fast enough. My group has a fair number of good female engineers.
Oh, citation: http://www.jsonline.com/story/...
And yet the state still has to cover the cost of things like unemployment, sewage treatment, roads and all the other things that Foxconn and their employees will make use of but won't pay for, since there will be no payroll taxes. The state will have to pay for unemployment when the jobs are automated away, and Illinois will clean up since many of the people will just commute from there over the border. Foxconn now gets the city and state to pay for maintaining all the roads for the workers without paying a dime. Similarly, there are all the other services Foxconn will use and again not have to pay for and the income taxes on the employees won't cover it. The employees won't be paid a huge amount either with an average wage of $53K. The payback time is only the best case scenario. The area already has very low unemployment with companies already having a hard time filling positions. The unemployment rate is 3.3%. It would make a lot more sense for Wisconsin to encourage the plant to be built in an area where there is high unemployment or underemployment, not a place where there is already full employment.
I have seen 35mm lenses that are designed to do just what you are describing. I know Nikon makes several tilt-shift 35mm lenses.
It most certainly IS a real shutter. Both of my DSLRs have real shutters and all of my past DSLRs have had real shutters just like the film cameras that preceded them. The shutter sits behind the mirror.
They most certainly do. Both of my DSLRs have real shutters. In fact, for long exposure mode, it takes two pictures, one with the shutter open and another with it closed to help remove noise from hot pixels. Many point and shoots use electronic shutters. What I miss is the electronic shutters of CCDs which activated the entire sensor at once so you don't get this rolling shutter crap from a lot of CMOS sensors. Unfortunately, CCD sensors suck at just about everything else compared to CMOS.
There is nothing preventing Samsung from adding their own APIs for the camera as long as they still provide the standard APIs for apps.
There are many situations where a phone camera will fall far short. A camera phone is fine if you can live with only one or two focal lengths and limited lighting conditions and don't care about controlling things like shutter speed, bokeh, noise, etc. A DSLR certainly makes things a lot easier. Many point and shoot cameras get in my way and actually prevent me from doing what I want to do. The last one I used went out of its way to prevent me from having any manual control.
One other big advantage with a good DSLR is the controls. With my DSLR I can instantly change many different settings without hunting through menus. I've found that many point and shoot cameras have done away with a lot of the controls I like, instead only having automatic modes like "pet mode" and crap like that. I want to be able to quickly adjust the exposure to how I want it, choosing shutter speed, aperture, ISO, white balance, etc. I also have a lot more control over the lighting by being able to adjust my flashes as needed. I can make most of these changes without ever having to take my eye off of my subject.
Having a variety of lenses is also a big benefit. In a couple of weeks, I'm driving up to photograph the eclipse and will be connecting the body of my camera to an 8" telescope which basically becomes a 2000mm lens which works great for this. Rather than have people peek through the eye piece I'm bringing an LCD monitor and an HDMI cable hooked up to my camera to make it easier for others to view it. On my other camera with an APS-C sensor, I'll use my 300mm zoom lens with a solar filter. Since I have a tracking tripod I can just use that for the camera with my 300mm lens.
I also can do a lot of things that are difficult or even impossible to do post processing, such as slapping on a circular polarizer filter to darken the sky or reduce reflections.
The best camera, however, is the camera you have. I've taken a fair number of photos with my Pixel camera and for quick snaps and panoramas it does a decent job, but it doesn't come close to a DSLR with my default zoom lens. For my Nikon D800 I typically use a 24-70mm f2.8 lens and my D300 I have a 17-55mm f2.8 for most of my photography. They're tack sharp. For low light stuff, I'll throw on a prime like my F1.4 50mm. I also love shooting shallow depth of field which is easy with a fast lens, especially with a full frame camera. The other thing with DSLRs is it isn't the body that's the important part, it's the glass. Camera bodies come and go but the lenses hold their value and old lenses typically work great with new bodies. Most of my lenses even work on old SLR cameras and lenses from the SLR days work on my DSLR.
Let's face it, a cell phone's camera and lens is probably no more than $10, maybe $20, maybe a bit more for a high end one.
Last Friday I got an Amazon Echo Dot and Google Home to play with and I have used Google's Android assistant for some time. My guess is that Samsung will have a lot of catching up to do. In playing with both Google and Amazon I have found that in most cases Google Home is superior to the Echo even though the Echo has been available longer. The home automation just seems to work better with Google Home. I can say "Hey Google, turn off all the lights" from my bed and all the lights in my house are turned off. Or "Hey Google, what lights are on?" to see if someone left one on. Asking for basic information Google Home is usually spot on. Amazon Echo either doesn't know or gives less precise data when it does. Both systems support my home automation, thermostat and even my car (I can monitor charging, turn on the AC, etc. of my car via both).
For search, Google is king. Alexa doesn't come anywhere close. I still need a chance to play more with the Chromecast integration and it sounds like more is coming. For example, Google Home will not play music via the video Chromecast yet. The best advantage with GH is that it works seamlessly with my phone and tablet so I just need to say "OK Google" and it works. I don't like the idea of purchasing stuff via voice and I still have a lot more to explore.
If I had that sort of overhead my software would not exist or work. Some of it has very tight memory constraints and besides, there would be no support for all the things one might expect. There's no heap, only a small stack available. Rust just isn't an option. Also, the entire toolchain is gcc, which precludes the use of Rust since Rust currently requires LLVM which does not have any of the optimizations that are required in order to allow the software to fit in the size constraints. Rust buys nothing but headaches. Many of Rust 'features' become hindrances, requiring a lot more overhead in terms of code space and efficiency. Remember, these are conditions completely different than some user-space application running on the command line.
Another killer for embedded use is the lack of the volatile keyword. This is essential, and "atomics" don't cut it. The lack of "volatile" pointers is a major killer, especially for dealing with hardware descriptors and memory mapped registers.
C handles these things quite well.
It is still not well supported. It certainly is NOT supported on the ESP32 I'm working with.
Rust is not all that portable. Rust is tied to LLVM. There are a lot more platforms supported by, say, GCC than LLVM. For example, I'm working on some Arduino and Xtensa based stuff at the moment. No Rust support but C and C++ are both supported. It's also trivial to link between C and assembly or for that matter C and just about any other language. I mix C and assembly all the time in the work that I do. I don't need any overhead of garbage collection, bounds checking, etc. either. The C calling ABI is very well documented and supported on all but the lowest end microcontrollers. If I write a library in C, it can be called from virtually any language. If I write a language in Rust, i doubt that would be the case. The C runtime library is pretty trivial. I've written bootloaders with only a page of assembly before calling the main function. By bootloader I'm referring to a true bootloader, code that is the first code executed when a CPU comes out of reset, not something called by the BIOS but code that will at some point load the BIOS.
I agree. If Firefox or Thunderbird is anything to go by I'd stay far away. I used Thunderbird for years until very recently but its performance is unusably bad. On my quad core xeon workstation it's almost impossible to write email because the editor freezes so frequently, often for seconds at a time. In the process it drops characters so I can't even type ahead. I suspect it's due to its single threaded nature and I'm dealing with several IMAP accounts with a LOT of emails. I recently switched over to KMail which seems to work far more smoothly. On top of that, Thunderbird is a huge memory pig. I gave up on Firefox ages ago and switched to Chrome due to horrible performance with single-threaded Javascript and the fact that it leaked memory like crazy for years. I also blame Mozilla for killing off MNG which is why we so often are STILL stuck with gif, which is a horrible format for most of the animations I see.
Rust has its place but it isn't going to replace C any time soon. There are other languages that also make the same claims, i.e. Go, Swift, D, etc.
One thing about C is it is supported on virtually everything except the micros where only assembly or some oddball language is the only thing supported (I used a processor that ran a pattern matching functional programming language at the hardware level once). There are plenty of other languages that are better than C in many cases, but one thing with C is you don't need to worry about libraries having weird interactions with other languages. C bindings are ubiquitous and very well understood and supported. C++ apps can easily link to and call C libraries but the other direction often requires some glue logic. Most languages can link against C code whereas the opposite is often not true. C has very minimal underlying requirements. I have written numerous bootloaders in C which require only around a page (or less) of assembly code. By boot loader, I'm talking about with no BIOS underneath for embedded systems. Cross compiling is well supported as well and I frequently am cross compiling for MIPS or AARCH64 with compilers that are tuned to the specific chips they're targeting.
I'm playing with an ESP32 device right now which has two Xtensia cores in it. No Rust support but C and C++ are both supported. There's no underlying operating system. Similarly, one doesn't run Rust on Arduino platforms. Rust is tied almost exclusively to LLVM. There is no GCC support for Rust so there are plenty of platforms where Rust just isn't supported.
C and C++ are supported by many toolchains, both open source and proprietary. Rust is not.
Rust developers seem to think that Rust is the answer to everything when it is not. I recall getting into an argument with a Rust developer over the fact that I refuse to even look at Rust. I write low-level boot loaders with a mixture of C and some assembly language for embedded systems where size can be a real premium and I'm working close to the hardware where things like pointer checking would cause a lot of problems and I don't have space for all the extra overhead (i.e. bounds checking, garbage collection, etc.) when every byte of space counts. In addition, I am cross compiling using the GCC toolchain optimized and tuned for the particular chips I'm working with (MIPS64 and ARMv8). Rust would be a big pain in the butt for the stuff I deal with where I frequently rely on the features of C that are considered "unsafe" like typcasting pointers to specific memory addresses, allocating memory without garbage collection, etc. While you can do those things with Rust, all of those Rust features get in the way and require language overhead of a run-time library (I don't have the C run-time library in many cases). Then there's the fact that I know the C cross compiler is very well supported and optimized for our architecture (we have a team of compiler people where I work). On the side I'm playing with an ESP32 (Xtensa CPU cores) device and Rust is not supported. C and C++ are supported, on the other hand. I was just looking at TLS support for a project I'm planning on the ESP32 and found an open-source cross-platform C library for it that works within its constraints, considering the fact that it does not have a real operating system. As far as I can tell, Rust is not supported at all on the ESP32 since LLVM is not supported (but gcc is).
I can throw C at basically anything. In some of the MIPS bootloaders I've written I need only about a page of assembly code before jumping to C code. There's no way I could do that with Rust.
No language is good at everything. C has a very long track record and is supported by virtually every CPU out there other than some extremely limited micros that only support assembly language or other oddball languages. (I once worked with a processor that executed a functional programming pattern-matching language in hardware that was incapable of running C). The FPL was basically assembly to this processor.
I don't know Rust other than what I've read about the language and I'm sure it has its place. One other thing to realize is that a lot of languages come and go.
Look at Java, for example. At one point there was a huge rush to support Java for everything but that has died down. One doesn't see many Java apps any more and I must say that it's always a major pain in the butt every time I need to use one now (especially since Oracle's Java RPM is broken and won't install without a lot of hacking... they screwed up the alternatives settings). Also, Oracle refuses to upgrade their Java plug-in to work with Chrome and modern plug-in interfaces.
C and C++ are very well established and have long track records and they are not controlled or dominated by any one company or group. I've also lost a lot of respect for Mozilla. The Firefox browser has been a disaster for a long time, and don't get me started on how bad Thunderbird is... Thunderbird on all of my systems is so slow I can barely type to compose an email due to its horrible single-threaded nature. I dumped Firefox for the most part a long time ago and haven't looked back. The horrible memory leaks and bad single-threaded Javascript killed it for me and they ignored the major problems for years. There's a reason Apple adopted KHTML for Webkit.
There are plenty of other similar programming languages, i.e. D, Go, Swift, etc. Only the test of time will prove its success. C and C++ have withstood the test of time, warts and all.
I tend to do a lot of builds and can definitely benefit from something like this since I can take advantage of all of those cores. There are numerous workloads that can certainly take advantage of more cores. Even at home, they come in handy when batch processing photos.
Bats are opportunistic feeders and while mosquitoes are a part of their diet they aren't a major part compared to larger insects. The elimination of disease carrying mosquitoes will not have a major impact on bats. They are not the main food source by any means and only make up a small part of their diet.
"studies of bats in the wild have shown that they consume mostly beetles, wasps, moths, and these same studies have shown that mosquitoes make up less than 1 percent of their total diet."
http://www.wbrcouncil.org/Depa...
Compared to the next oldest car company they are. The last time an American car maker went public was Ford in 1956. The last time a major US car company that still exists was founded was 1925 (Chrysler), though some may argue about the fact that Chrysler is now owned by Fiat (founded in 1899). By comparison, Tesla is certainly a start-up.
With hardware acceleration AV1 is not that battery intensive. Just about everyone is adopting AV1 except Apple. What makes a big difference is if the underlying hardware supports offloading AV1 encoding and decoding. All of the major hardware vendors will support AV1, including Intel, AMD, ARM and Nvidia. Apple is the lone holdout. Most web browsers except Safari support AV1 which builds on VP9. VP9 is also not supported by Apple.
That reminds me of when my parents' neighbor accidentally dug up the cable line that ran to my parents' house and "fixed" it with wire nuts.
It's probably pretty good with the right tires. The weight is all down low and it has a massive amount of low-end torque, not to mention very good traction control. It also has a very stiff body. While it may not have as high of clearance as some other cars (though with active suspension it can raise itself), other than that it should do quite well. http://insideevs.com/tesla-mod...
We have Sonicwall at work. Unfortunately it requires running Java in the browser to connect to it through Linux.
Years ago I worked on an ipsec product and was successful getting it to work. The problem is that since then the complexity has increased significantly. Making matters worse is that different commercial products do it differently. Linux to linux is one thing, because one can easily verify that all of the appropriate settings are the same. Linux to a commercial box, on the other hand, is a big problem.
For example, my home router, a Mikrotik box, has a bazillion options for ipsec but trying to figure out the correct combination to make it actually work is a major pain in the butt. IPSec's problem is that it is so complex, and when it comes to commercial products they often offer a driver for Windows and maybe Mac but when it comes to Linux you're often out of luck when it comes to connecting to them, though they may offer some Java in the browser (ugh) thing.
Something needs to happen.
Last night I tried to get pptp to work with our corporate VPN and it failed miserably. I ran Wireshark to figure out what the problem is and the Linux PPP stack just can't handle the options that it was being sent (bug opened on pppd). Next I tried to connect to my home firewall VPN which used to work and again this failed miserably because the Linux PPP stack refused to turn off the async char map negotiation (which isn't used for PPTP).
I've also struggled to get ipsec in any form to work (no success) nor have I been able to get openvpn to work, requiring all the generation of certs and whatnot. PPTP, despite being quite insecure, at least used to work before the modern PPP brokeness.
The problem with VPNs is that the solutions are overly complicated with a bazillion different options.
IPSec + L2TP!?!?! This is insane. PPTP is just plain broken as well.
I want something as simple as how PPTP used to work but without all the broken security (i.e. MD5 password hashes) and get rid of PPP.