For the same reason they're convinced net neutrality is bad because it denies their corporate donors of their god given dollars. It's the same reason they're against having a consumer financial protection bureau or against banking regulations or environmental regulations or anything else that interferes with their corporate overlords.
What we need is an amendment that clears the money out of politics. As far as I'm concerned, campaign contributions and PACs are legalized bribes and I say this as someone who contributes to some candidates. The other huge problem is that politicians often get deals so that as soon as they're out of office they make big bucks working for a certain industry which they previously had to write legislation for.
Sadly that's often how things work, money talks. I like the system Arizona used to have where if one candidate took in private campaign contributions the state would match contributions to the other candidate if they publicly financed their campaign. Sadly this was struck down by the conservative branch of the supreme court who like to think that money == speech.
I have been using XFS for many years and have found it to be quite reliable and have been able to recover data when the underlying data store got corrupted. It's also quite mature in Linux and relatively fast. My last experience with BTRFS was a failure (several years ago) due to it being incredibly slow when there were thousands of small files in directories. Once ZFS is stable in the Linux kernel I'll give it a try.
I think in any event it's exciting to see these advancements in battery technology and I can't wait until they make it out of the lab. I'm sure companies like Tesla are looking at this technology very carefully.
The problem I've run into as an interviewer is that a lot of candidates lie or pad their resumes. I have also seen names on patents that don't belong there (and one case where my name should have been on there). As an interviewee I've never been afraid to say when I don't know something. It's far better than trying to BS your way through an interview.
I wouldn't hire you either if you answered like that. If something is on your resume I'm going to ask about it.
If you tried to pull that when myself or anyone else on my team were interviewing you your resume would immediately go into the bitbucket. The problem with those ready-made algorithms is that they are not always ideal depending on the data being sorted. Also, it helps weed out the programmers from the engineers. I give a relatively simple programming problem that could easily be done with a common function call. I want to see how the candidate approaches the problem and there are multiple ways to solve it. It works well at weeding out crappy engineers who rely on stackoverflow for everything.
We also work in environments where you can't just call some sorting function because there's a good chance it doesn't exist. We also expect basic knowledge. That's the difference between a programmer and an engineer.
For example, there are numerous cases where quicksort is not the best algorithm.
I've had to implement common data structures from scratch many times because either the generic functions were not available or they were sub-optimal for the task at hand.
That reminds me of having to deal with malloc in VxWorks 5.4. VxWorks kept track of free memory blocks in a sorted linked list from the smallest to the largest block. One of the libraries I dealt with needed to use realloc() a lot to increase data structures as large trees of data were filled in (data for a network processor that did longest prefix match in hardware). The problem with this is that just booting up we'd end up with tens of thousands of tiny free blocks and the bootup time was around an hour because realloc would look for a larger block size and would walk through all those tiny free blocks. The bootup time was around an hour and long term stability was impossible due to heap fragmentation.
I replaced the VxWorks malloc implementation with Doug Lei's implementation (which glibc is based off of, or at least used to be). Startup time went from an hour to three minutes and the fragmentation issue disappeared entirely. Additionally I added some instrumentation that made it trivial to track down memory leaks at run-time on a system in the field. One command would show how many blocks and how much memory was allocated by each function and task. (VxWorks is a multi-tasking real-time operating system that used a single address space for all tasks).
It works for quick and dirty on very small data sets though I agree that in general it's not used. I've benchmarked code dealing with a small data set where a linear search on unsorted data was faster than trying to maintain sorted data despite one being O(n) and the other being O(logn)
It depends on the environment you work in. For example, I know that in one code base that Palo Alto Networks uses that you don't have access to functions like qsort since it is an embedded environment, and ready-made sorting functions are not always ideal if you know something about the data beforehand. These "hand-optimized" generic functions are also just that, generic, and hence there are many cases where a different sorting algorithm may make more sense compared to qsort. I also give a programming problem that one could easily solve with a simple library function because there have been numerous cases where such a function is not available (it's a pretty common function). In addition, by asking the person to write the function I can see how they approach the problem.
I've dealt with PAN and they certainly do have real critical thinking skills. If I interviewed you and you behaved that way you'd get a quick no-pass from me and my team as well. And yes, I have in the real world dealt with problems where one has had to implement sort routines, including one environment I know PAN uses (though I have never worked for PAN I work on a codebase that they use for an embedded bare-metal environment). Since I work for a vendor who supplies parts to PAN I've been submitted problems by PAN and their engineers typically know what they're talking about.
That's like me. I could discuss various minutia about 10G, 25 and 40G Ethernet or details on SFP+ modules or temperature sensors, SATA, USB and a host of other things that would bore them to death. Just don't ask me details about x86 because most of my work has been with MIPS and am now starting ARMv8. I could talk to them for hours about MIPS assembly language, for example, or how virtual memory works on it.
I totally agree. I've been a software engineer for over 20 years and most of my experience is with C and assembly dealing with hardware issues, device drivers and bootloaders. I'm quite rusty on the details of object oriented programming and couldn't tell you the difference between an abstract class vs a regular class. I don't usually deal at the level of binary trees, though telling if a tree is balanced or not is a fairly simple recursive problem. Now if you ask me about things like i2c, SPI, flash, CPU caches and some low-level networking things I'd do quite well.
I haven't dealt with binary trees in ages and my C++ experience was many years ago.
I remember when AT&T took over my @Home cable modem service. The prices went way up and the service got really really bad. Back when I had @Home I had 10Mbps down and 1Mbps up (originally 10M up and down). Back then that was still pretty insane. Then AT&T took it over and it became ATTBI. AT&T decided that 1Mbps was too much bandwidth and lowered it to 128Kbps up. On top of that, they aggregated EVERYONE's bandwidth through the same 128Kbps, so now I'm sharing 128Kbps up along with all of my neighbors. At the best of times with ping I only got 40% packet loss. Needless to say, dial-up was a lot faster than my "broadband". It was like this for 9 months. AT&T support consisted of "did you reboot your computer and router and modem?" which, of course, did absolutely nothing. AT&T eventually fixed it, but even newspaper articles describing their crappy service didn't change matters.
Finally Comcast took it over and Comcast was a godsend compared to AT&T. You know things are bad when you praise Comcast. Even Comcast's crappy customer service is orders of magnitude better than what I experienced with AT&T.
I will NEVER use AT&T again. I currently use Comcast business, which, while expensive, is much better than residential.
I have a 4 year old Tesla model S with 50,000 miles on it. I have not noticed any loss of range or performance. The general consensus among owners is that there is a 5% loss of range at 100K miles. Now Tesla has a much better battery thermal management system and a better chemistry than a number of other manufacturers (i.e. Nissan, GM, etc.)
Tesla is NOT using the same battery tech as everyone else. Here's a good talk about them.. Dr. Jeff Dahn is one of the foremost experts on battery failure.
Tesla also has active battery thermal management using liquid cooling. The Nissan Leaf, by comparison, does not. Tesla's chemistry is also a lot better than the chemistry used in the Leaf.
At 100,000 miles the consensus is that an 85KWh battery still has 95% of its capacity. The batteries are also designed for automotive use with active heating and cooling as necessary. Laptop batteries are not designed for longevity, nor do they have active temperature control. Laptop batteries (and other consumer device batteries) are usually designed primarily with cost and capacity in mind. As long as they last as long as the warranty that's all they care about. Furthermore, laptops don't treat their batteries very well. Lithium ion batteries really hate being fully charged for any length of time and being fully discharged. When I researched the batteries used in my Tesla model S it showed them having over 70% capacity after 3000 full charge/discharge cycles. Assuming 200 miles per charge (actually it's a fair amount more) that works out to 600,000 miles.
Generally one doesn't charge the car to 100% or drive it down to 0% either. The car lets you choose how much you want to charge it and warns you if you choose over 90%. I am just shy of 50,000 miles and I haven't noticed a drop in range or performance in the four years I've had my car.
Things are rather different for airplanes than cars. Airplanes are far more complex in terms of what can go wrong, however for the most part autopilot is simpler. My model S already checks the tire pressure. If the car is iced up it likely won't drive itself either, since obviously all the cameras need to work as well as the ultrasonic sensors and radar.
The reliability of a car also does not need to match that of an airplane since with a car you can usually just pull over. With an airplane carrying a lot of passengers it's a whole different story. It's not like it can just pull over and stop at 30,000 feet.
Mechanically they're night and day. The number of moving parts in a Tesla's drivetrain is a small fraction of what it is in a gasoline or hybrid vehicle which is a lot simpler than an airplane. The car already monitors just about everything as it is such as battery temperature, current/voltage, coolant temperature, air temperature, tire pressure, traction control, stability control, etc. There's even a rain/snow sensor. The autopilot feature also won't work if the car can't see the road clearly and it's not supported if it's raining or snowing. The car even monitors the state of the 12v battery. In my model S it warned me before it failed, and my car is a first generation model.
The car also is paying attention to a lot more than a driver can, since with 8 cameras and other sensors it is constantly looking all around the vehicle. It doesn't get distracted either by kids in the back seat, changing radio stations, or cell phones. The software will continue to improve as time goes on.
You cite an anecdotal article which does not apply to where most people are complaining about voter ID. Many elderly people, for example, lack an ID. In some rural areas it is also difficult to get an ID since the DMV is often a significant distance away and is open for a limited number of hours, often during working hours. Harlem has a very different makeup than rural areas and access to an ID is far easier.
Here is a better article. About 11% of Americans do not have government issued photo identification cards. A federal court in Texas found that 608,740 registered voters didn't have the forms of identification required for voting.
The amount of voter fraud in the United States is exceedingly low so the whole voter ID laws are a solution in search of a problem. Out of 1 billion votes cast there were 44 cases of fraud, a rate of 0.0000044%.
There is also widespread evidence that such laws are designed to target democratic voters and that they tend to target the poor and minorities.
Many of these IoT devices have small amounts of memory and do not run Linux. Even those that do run Linux, understanding C is still a must when you deal with hardware. I'm sorry for you, but the embedded world is based almost entirely on C, not Rust or any other language. Learning C for embedded work is essential. You'll get a lot further knowing C than knowing Rust or even Python (which is making some inroads). The most valuable jobs basically all require C.
I agree with you about the overhead. The C++ overhead is generally minimal which I always find I have a hard time convincing people of. Back in the day all of my debugging was at the assembly level because there was no source level debugger for kernel device drivers.
Write barriers also guarantee that the data is actually written to memory. On many platforms (i.e. MIPS) when you write to memory with a store instruction it may not actually be written to the cache but sit in a write combining buffer. Also there are different sync instructions where some preserve the order and others don't. One has to explicitly issue a sync instruction in order to flush the write buffer to the L2 cache. If the processor is not cache coherent (like a number of processors I've used) then you also need to explicitly flush or invalidate the cache as needed. Of course all of this also depends on where the write is. Writes to I/O registers typically don't need the synchronization.
You talk about closing a file. We're talking kernel level here. Rust may work well in user space, not so much at the kernel level. None of that "management" exists. Guard pages? What are those? What's this virtual memory thing you're talking about?
Slashdot Mirror
I understand Utah is one of the biggest consumers of porn. while at the same time rejecting teaching sex education in school.
For the same reason they're convinced net neutrality is bad because it denies their corporate donors of their god given dollars. It's the same reason they're against having a consumer financial protection bureau or against banking regulations or environmental regulations or anything else that interferes with their corporate overlords.
What we need is an amendment that clears the money out of politics. As far as I'm concerned, campaign contributions and PACs are legalized bribes and I say this as someone who contributes to some candidates. The other huge problem is that politicians often get deals so that as soon as they're out of office they make big bucks working for a certain industry which they previously had to write legislation for.
Sadly that's often how things work, money talks. I like the system Arizona used to have where if one candidate took in private campaign contributions the state would match contributions to the other candidate if they publicly financed their campaign. Sadly this was struck down by the conservative branch of the supreme court who like to think that money == speech.
I have been using XFS for many years and have found it to be quite reliable and have been able to recover data when the underlying data store got corrupted. It's also quite mature in Linux and relatively fast. My last experience with BTRFS was a failure (several years ago) due to it being incredibly slow when there were thousands of small files in directories. Once ZFS is stable in the Linux kernel I'll give it a try.
I think in any event it's exciting to see these advancements in battery technology and I can't wait until they make it out of the lab. I'm sure companies like Tesla are looking at this technology very carefully.
The problem I've run into as an interviewer is that a lot of candidates lie or pad their resumes. I have also seen names on patents that don't belong there (and one case where my name should have been on there). As an interviewee I've never been afraid to say when I don't know something. It's far better than trying to BS your way through an interview.
I wouldn't hire you either if you answered like that. If something is on your resume I'm going to ask about it.
Now try that in C in an embedded environment without the qsort function.
If you tried to pull that when myself or anyone else on my team were interviewing you your resume would immediately go into the bitbucket. The problem with those ready-made algorithms is that they are not always ideal depending on the data being sorted. Also, it helps weed out the programmers from the engineers. I give a relatively simple programming problem that could easily be done with a common function call. I want to see how the candidate approaches the problem and there are multiple ways to solve it. It works well at weeding out crappy engineers who rely on stackoverflow for everything.
We also work in environments where you can't just call some sorting function because there's a good chance it doesn't exist. We also expect basic knowledge. That's the difference between a programmer and an engineer.
For example, there are numerous cases where quicksort is not the best algorithm.
I've had to implement common data structures from scratch many times because either the generic functions were not available or they were sub-optimal for the task at hand.
That reminds me of having to deal with malloc in VxWorks 5.4. VxWorks kept track of free memory blocks in a sorted linked list from the smallest to the largest block. One of the libraries I dealt with needed to use realloc() a lot to increase data structures as large trees of data were filled in (data for a network processor that did longest prefix match in hardware). The problem with this is that just booting up we'd end up with tens of thousands of tiny free blocks and the bootup time was around an hour because realloc would look for a larger block size and would walk through all those tiny free blocks. The bootup time was around an hour and long term stability was impossible due to heap fragmentation.
I replaced the VxWorks malloc implementation with Doug Lei's implementation (which glibc is based off of, or at least used to be). Startup time went from an hour to three minutes and the fragmentation issue disappeared entirely. Additionally I added some instrumentation that made it trivial to track down memory leaks at run-time on a system in the field. One command would show how many blocks and how much memory was allocated by each function and task. (VxWorks is a multi-tasking real-time operating system that used a single address space for all tasks).
It works for quick and dirty on very small data sets though I agree that in general it's not used. I've benchmarked code dealing with a small data set where a linear search on unsorted data was faster than trying to maintain sorted data despite one being O(n) and the other being O(logn)
It depends on the environment you work in. For example, I know that in one code base that Palo Alto Networks uses that you don't have access to functions like qsort since it is an embedded environment, and ready-made sorting functions are not always ideal if you know something about the data beforehand. These "hand-optimized" generic functions are also just that, generic, and hence there are many cases where a different sorting algorithm may make more sense compared to qsort. I also give a programming problem that one could easily solve with a simple library function because there have been numerous cases where such a function is not available (it's a pretty common function). In addition, by asking the person to write the function I can see how they approach the problem.
I've dealt with PAN and they certainly do have real critical thinking skills. If I interviewed you and you behaved that way you'd get a quick no-pass from me and my team as well. And yes, I have in the real world dealt with problems where one has had to implement sort routines, including one environment I know PAN uses (though I have never worked for PAN I work on a codebase that they use for an embedded bare-metal environment). Since I work for a vendor who supplies parts to PAN I've been submitted problems by PAN and their engineers typically know what they're talking about.
That's like me. I could discuss various minutia about 10G, 25 and 40G Ethernet or details on SFP+ modules or temperature sensors, SATA, USB and a host of other things that would bore them to death. Just don't ask me details about x86 because most of my work has been with MIPS and am now starting ARMv8. I could talk to them for hours about MIPS assembly language, for example, or how virtual memory works on it.
I totally agree. I've been a software engineer for over 20 years and most of my experience is with C and assembly dealing with hardware issues, device drivers and bootloaders. I'm quite rusty on the details of object oriented programming and couldn't tell you the difference between an abstract class vs a regular class. I don't usually deal at the level of binary trees, though telling if a tree is balanced or not is a fairly simple recursive problem. Now if you ask me about things like i2c, SPI, flash, CPU caches and some low-level networking things I'd do quite well.
I haven't dealt with binary trees in ages and my C++ experience was many years ago.
You just need a giant lens in front of it like those monitors in the movie Brazil.
I remember when AT&T took over my @Home cable modem service. The prices went way up and the service got really really bad. Back when I had @Home I had 10Mbps down and 1Mbps up (originally 10M up and down). Back then that was still pretty insane. Then AT&T took it over and it became ATTBI. AT&T decided that 1Mbps was too much bandwidth and lowered it to 128Kbps up. On top of that, they aggregated EVERYONE's bandwidth through the same 128Kbps, so now I'm sharing 128Kbps up along with all of my neighbors. At the best of times with ping I only got 40% packet loss. Needless to say, dial-up was a lot faster than my "broadband". It was like this for 9 months. AT&T support consisted of "did you reboot your computer and router and modem?" which, of course, did absolutely nothing. AT&T eventually fixed it, but even newspaper articles describing their crappy service didn't change matters.
Finally Comcast took it over and Comcast was a godsend compared to AT&T. You know things are bad when you praise Comcast. Even Comcast's crappy customer service is orders of magnitude better than what I experienced with AT&T.
I will NEVER use AT&T again. I currently use Comcast business, which, while expensive, is much better than residential.
I have a 4 year old Tesla model S with 50,000 miles on it. I have not noticed any loss of range or performance. The general consensus among owners is that there is a 5% loss of range at 100K miles. Now Tesla has a much better battery thermal management system and a better chemistry than a number of other manufacturers (i.e. Nissan, GM, etc.)
Degradation turns out to be around 23 miles per 100,000 miles driven.
Here's an excellent talk by one of the foremost experts on lithium ion battery degradation.
Tesla is NOT using the same battery tech as everyone else. Here's a good talk about them.. Dr. Jeff Dahn is one of the foremost experts on battery failure.
Tesla also has active battery thermal management using liquid cooling. The Nissan Leaf, by comparison, does not. Tesla's chemistry is also a lot better than the chemistry used in the Leaf.
At 100,000 miles the consensus is that an 85KWh battery still has 95% of its capacity. The batteries are also designed for automotive use with active heating and cooling as necessary. Laptop batteries are not designed for longevity, nor do they have active temperature control. Laptop batteries (and other consumer device batteries) are usually designed primarily with cost and capacity in mind. As long as they last as long as the warranty that's all they care about. Furthermore, laptops don't treat their batteries very well. Lithium ion batteries really hate being fully charged for any length of time and being fully discharged. When I researched the batteries used in my Tesla model S it showed them having over 70% capacity after 3000 full charge/discharge cycles. Assuming 200 miles per charge (actually it's a fair amount more) that works out to 600,000 miles.
Generally one doesn't charge the car to 100% or drive it down to 0% either. The car lets you choose how much you want to charge it and warns you if you choose over 90%. I am just shy of 50,000 miles and I haven't noticed a drop in range or performance in the four years I've had my car.
Things are rather different for airplanes than cars. Airplanes are far more complex in terms of what can go wrong, however for the most part autopilot is simpler. My model S already checks the tire pressure. If the car is iced up it likely won't drive itself either, since obviously all the cameras need to work as well as the ultrasonic sensors and radar.
The reliability of a car also does not need to match that of an airplane since with a car you can usually just pull over. With an airplane carrying a lot of passengers it's a whole different story. It's not like it can just pull over and stop at 30,000 feet.
Mechanically they're night and day. The number of moving parts in a Tesla's drivetrain is a small fraction of what it is in a gasoline or hybrid vehicle which is a lot simpler than an airplane. The car already monitors just about everything as it is such as battery temperature, current/voltage, coolant temperature, air temperature, tire pressure, traction control, stability control, etc. There's even a rain/snow sensor. The autopilot feature also won't work if the car can't see the road clearly and it's not supported if it's raining or snowing. The car even monitors the state of the 12v battery. In my model S it warned me before it failed, and my car is a first generation model.
The car also is paying attention to a lot more than a driver can, since with 8 cameras and other sensors it is constantly looking all around the vehicle. It doesn't get distracted either by kids in the back seat, changing radio stations, or cell phones. The software will continue to improve as time goes on.
Of course you provide no citations.
You cite an anecdotal article which does not apply to where most people are complaining about voter ID. Many elderly people, for example, lack an ID. In some rural areas it is also difficult to get an ID since the DMV is often a significant distance away and is open for a limited number of hours, often during working hours. Harlem has a very different makeup than rural areas and access to an ID is far easier.
Here is a better article. About 11% of Americans do not have government issued photo identification cards. A federal court in Texas found that 608,740 registered voters didn't have the forms of identification required for voting.
The amount of voter fraud in the United States is exceedingly low so the whole voter ID laws are a solution in search of a problem. Out of 1 billion votes cast there were 44 cases of fraud, a rate of 0.0000044%.
There is also widespread evidence that such laws are designed to target democratic voters and that they tend to target the poor and minorities.
Many of these IoT devices have small amounts of memory and do not run Linux. Even those that do run Linux, understanding C is still a must when you deal with hardware. I'm sorry for you, but the embedded world is based almost entirely on C, not Rust or any other language. Learning C for embedded work is essential. You'll get a lot further knowing C than knowing Rust or even Python (which is making some inroads). The most valuable jobs basically all require C.
I agree with you about the overhead. The C++ overhead is generally minimal which I always find I have a hard time convincing people of. Back in the day all of my debugging was at the assembly level because there was no source level debugger for kernel device drivers.
Write barriers also guarantee that the data is actually written to memory. On many platforms (i.e. MIPS) when you write to memory with a store instruction it may not actually be written to the cache but sit in a write combining buffer. Also there are different sync instructions where some preserve the order and others don't. One has to explicitly issue a sync instruction in order to flush the write buffer to the L2 cache. If the processor is not cache coherent (like a number of processors I've used) then you also need to explicitly flush or invalidate the cache as needed. Of course all of this also depends on where the write is. Writes to I/O registers typically don't need the synchronization.
You talk about closing a file. We're talking kernel level here. Rust may work well in user space, not so much at the kernel level. None of that "management" exists. Guard pages? What are those? What's this virtual memory thing you're talking about?
I'd say it's higher level since it requires a forth interpreter. Forth doesn't run very well without an interpreter.