Huh? Back in the early '80s to mid '90s Toyota was all STAR, extremely proprietary. At the same time GM was simple which became OBD. Ford was all analog (think +/-10V and ADCs) and then went to a simple multiplexed scheme. The only 'standard' was the European makes that used BOSCH as the OEM, since they were all similar (even the connectors).
No the downfall of quality of Toyota was simply this. Up until the '70s they were not very good quality. They decided to improve this. Back then the paragon of quality was Mercedes. So Toyota bought a number of W116 chassis models and tore them apart. Then they ridiculously over engineered everything in the same style.
Now they wanted to become the sales leader in the world. They started letting their suppliers do more of the design and bought off the shelf. You could see the beginning of the end when the multicolored bolts disappeared and low quality cheap ones took their place in the late '90s.
I think you have not scene many car accident scenes. It is often hard to tell what could have happened based on where the cars are after the accident. There does tend to be a lot of chaotic behavior.
The chopping off the bottom 4cm is a bad sign. They are not supposed to do this last I heard. It seems to me that they have taken a shortcut for inserting the shim. The service bulletin instructs them to remove the pedal assembly in order to insert the shim. By removing the bottom of the gas pedal they have room to wedge that shim in there without the laborious process of removing and reinstalling it. Also there is more risk that they can get grim in there then (though in the tech is supposed to wipe the outside yet not use compressed air to minimize risk of getting dirt inside).
Also if you have a Camry it is possible that you have a Denso pedal assembly that did not need the shim if I recall correctly. Maybe there is bulletin that is different for those that I am not aware of.
If I were you I would take your car to another Toyota service and have them look at it. Then if they say that is unusual, they should contact Toyota in order to for Toyota to authorize the replacement of your gas pedal assembly. They are supposed to measure pedal travel on a workbench, I really wonder why they chopped off the bottom of yours maybe it was very bad? If I am wrong then you will have had any concerns addressed.
Also the floor mat is a new one with restraints, not that they lopped off chunks of your old one and held it down with something like zip ties, right?
Or the hand brake especially if you have a manual and only two feet.
Seriously they are going to have to have something like the brake is depressed by at least so much say 75% for at least a certain duration say a second for this to kick in. Otherwise how would all the Toyota drivers that I see who rest their left foot on the brake get anywhere?
Thank you very much. It seems that your toolchain aligns structs in the natural way that X86, SPARC, and PPC do. That's great! I guess it assumes you have load and store word that work right. What toolchain and version are you using?
I had to port old code on another occasion that assumed everything other than char and unsigned char was aligned on 2-bytes, that was annoying as well. That's probably what you have on your hands as well. I feel your pain.
Again what I did is I compiled (this time everything since the PPC was SO much faster than the 8088) with that -fpack-struct option and added the xyz_padN members where needed. But first I needed to change all the int, unsigned, unsigned int, to int16_t and uint16_t, and similarly for other types. And then I had all the byte order assumptions to deal with, joy.
Again thanks for the info about natural alignment becoming the norm on newer ARM cores.
Yeah I used gcc cross compiler, it was installed as ccarm when I did ARM stuff, I just used cc as a generic term for "C Compiler."
I'm waiting eagerly since I had SO MUCH network code that did not work right due to the extra padding of shorts in structures to make such structures always 32-bit aligned. I would send and receive using sizeof and so many things would end-up having extra 2 bytes of padding here and there being not at all what I expected at first and of course not working between ASM, X86, and SPARC versions.
Back then I think I could only apply the packed attribute to an entire structure not individual members and these were header files I had not written. I ended-up putting the troublesome functions in seperate C files and compiled them with -fpack-struct or some such option and I put explicit int8_t xyz_padN (N = 0, 1, 2,...) members in them so things would line-up correctly for ARM packed structs and other archs that were compiled without the option. It was a true PITA with lots of use of cscope.
psize.c: typedef struct {
unsigned char a;
unsigned short b;
unsigned short c; } pstruct;
int psize = sizeof (pstruct);
$ cc -c foo.o
And then dump out psize to see what it is. My guess is it will be 8 instead of 6, but that was since my tool chain did not assume ldhw. If I put the packed attribute on member c, then it would be 6, but then the code would have many ldb instructions.
So maybe I am dating myself, is it now common for tool chains to simply assume ldhw is there and no longer align to 32-bits in such cases like above? (ie there would be only one byte of padding after member a.) Also I used to get a useful rotation if I had the bits set to little endian and not to trap on misaligned access. Is that now no longer the case?
For example if I had this at address zero (for simplicity sake):
01234567 89abcdef
and I loaded this:
long v = *((long *)2);
Then v would be 0x23016745 if memory serves. Now that would be 0xab896745?
You have a struct { int8_t a; int16_t b; int16_t c; }
It will get layed-out on PPC, SPARC, and X86 like so:
a0bbcc
Will it get laid-out in ARM like so?
a0bbcc00
That's how things were often configured in ARM toolchains because in this way the same sequence of instructions can be used to access an array of such structures, not a different sequence for the ones that are aligned on 32-bits and those that are not. Do you loose the useful rotations with misaligned loads with Cortex then?
The strict alignment is already there in portable code since on PPC floats and doubles (and vector types) need to be aligned properly and on SPARC every type needs to be. But what I described above is a different wrinkle about how things get padded that can and does trip-up coders since they are new to it.
Everyone mentions ZFS and Dtrace, I will really miss mdb if solaris ever goes away. mdb is the single best debugger ever created. I have shell scripts that use truss to stop on an bug in closed source code, then use mdb to change some registers, and then use prun to carry-on. That completely ignores all the useful dcmds too.
There are in Miami and near Madison Wisconsin. They are both very nice for sun bathing and bathing, though recently the there have been young people drinking and being stupid in Wisconsin, and the number of 'prairie dogs' (single males standing staring) are starting to get high in Miami. So in Wisconsin stay in the more crowded areas and in Miami either be in the more gay areas in the very north or the topless areas south.
There are other beaches, but some of them are not officially nude and others are just not pleasant due to being rocky or windy. Those two are very nice.
No actually the same problem exists in cap and trade. There has to be an honest way to count how much greenhouse gasses a company emitted into the atmosphere in a year and how many tons of CO2 is that equivalent to.
Rather than CAT, why not simply tax the company that removes the material from the earth. It's pretty easy to know how many tons of coal a company mined in a year as it simple to know how many gallons of crude were pumped. Now every other company picks that up as an increased cost along the way.
Those taxes collected can then be simply given as tax rebates to tax payers to partially offset the costs associated with global warming and the increased costs of goods and services. Or a government could loan it towards emissions reduction programs, largely in the developing world, with attractive long term returns.
There is one more mechanism, the one used most often. For counties that signed on to Kyoto the certificates are managed by the UN and traded in a primary market largely in London (as well as the large secondary market now as well). The vast majority of current certificates in these markets tend to be for projects in a developing country. What happens is some company (usually not the carbon emitter itself) proposes a plan to a UN agency that basically says that right now some company in Brazil or where ever is emitting the equivalent of so many tons of CO2 per year. If the proposing company can raise $X it has a plan to over Y years (say 10) reduce the tons of CO2 emitted per year by that Brazilian company by Z. Then the UN grants the certificates, and they get sold on the London market. Then they get traded in the secondary markets. So now the companies that hold these certificates can not worry about what ever number of tons of CO2 it is that they bought. The company that issued the approved certificates is now supposed to invest that money into the CO2 reduction project. Seems great but what are the problems?
In practice what has been happening is that there are all the derivatives markets now on all of that paper. So the companies that have the proposed projects only use a fraction of the money on the actual projects themselves, rather they invest most of that on futures for that CO2 and whatnot in order to hedge and hopefully profit in their investments in the derivatives they buy, sell, and exercise.
So does in fact the Brazilian company reduce CO2 emissions in 10 years by Z tons per year? Who knows what will happen, but in the meantime the companies that bought the certificates were able to pollute above their limits. Also all the people involved in the huge markets could have been making very good returns. These people are not likely to police themselves well when the Brazilian company two years later has reduced it C02 emissions by Z/20 thanks to the projects and then goes and sells its credits under shell company shenanigans likely on the secondary poorly regulated market.
The tax on the other hand only has the issue of making sure that CO2 is counted correctly. The government does not even need to use those taxes to fund CO2 reduction programs or anything of the sort. It could simple accept that due to such taxes costs will increase and it could simply distribute them to the taxpayers to somewhat offset that. Then there will only be genuine cost vs time to profit thinking by emitters.
The cap and trade scheme creates some new markets that are larger than any other. It is a boondoggle for investment firms and banks. A tax would not create that. To some that is a positive or negative aspect, but it lends itself to performing very poorly to actually reduce greenhouse gas emissions if not regulated well. It also lends itself to very disruptive speculation that effects energy and ultimately all costs without any of the offset from a tax rebate program.
That said there have been some markets that have in fact been well regulated, so it can be done, but it is not in this case.
Hmmm... Doom was okay on a 33MHz 486DX with 128KB of ecache for single player (stayed above 15 FPS), but for network death match with DEC tulip based ISA NICs using thin coax it would lag and play at 10-12 FPS on that box. The 50MHz 486DX2 and 75MHz 486DX4 did okay. Also there was a 40MHz 386 with a 3COM NIC ISA card that could hold it's own, it did have a Paradise 16-bit ISA SVGA card, the others were Trident and Cirrus Logic, and it did not lag but the frame rate was in the 10-12 FPS range too in deathmatch. All from memory, but man did I not like being stuck with that 33MHz 486.
Sorry that is NOT to spec for NTSC DVD. About the only HxW issue I ever see in testing is that some NTSC DVD players do not display the half height (240) format properly. Usually the image is squished on the top half of the TV. Fortunately VCD was never popular in NA so it is very rare to encounter a DVD that uses VCD-ish MPEG2 video.
Personally I waited and bought the first Panasonic DVD player that did not have any bugs. All previous players from every other vendor had audio, subtitle, VM, and chroma filter issues. That $800 DVD player was the first that really worked with everything. It still works. To this day I run into DVDs that do not work right is some of my other cheap DVD players.
Things that will be useful from math for the practical programmer:
combinatorics linear algebra analysis and differential equations
Get as much of those as you can, if they get too hard stop.
Some times statistics courses are best for the combinatorics stuff. You will run into problems that are shuffling things around efficiently, that is where that is useful. Some of the graph theory stuff though may not come from the lower numbered statistics courses though, but you should get enough of that from CS courses. The statistics will give you background for things such as RMSE that come-up in practical coding.
The linear algebra and differential equations often come from math courses targeted towards engineering and physics students. Basically any hard problem that is solved by approximation comes down to an algorithm that is essentially a bunch of linear algebra. Then in many practical areas you need knowledge of things like FFT, PID, etc and the analysis as apposed to discrete math helps there. For a lot of these things if you just have enough knowledge so that you can understand some article, papers, and docs, then it is much easier to use libraries that others have written. That is why you should not fret if too much if the math gets too hard.
Other than that you should get enough abstract algebra and other discrete math from your CS courses. Along the same lines, you should stay away from geometry, it tends to be abstract algebra in disguise, and algorithms courses will have what you may have wanted presented in a way that is useful for programming. Logic is another area that is not very applicable to the practical programmer. You should get enough in some CS courses and some proofs that use applicable techniques there as well as in the combinatorics.
That said if you want to pursue CS, then all the above is VERY poor advice. Then you need as much logic and math as possible. You should love it too.
I use SCCS to this day. I like it very much for situations where I am working on some files in SVN or CVS and I am still experimenting. So that I can easily go back when things do not work-out I use sccs edit and delget before I try something new, the way I might have copied to a foo.c.bak or foo.c.3 without SCCS. Then I just cvs or svn commit that dir when I have some good code.
That's largely because of the warts in CVS and SVN though.
That is true. It was evidently clear from the initrd image that this was tweaked reference board hardware. The frustrating thing was that identical model numbers used different components that used different versions of firmware. It appeared that the firmware update I got had support for more TVs, ie some of the ones made earlier, but not all others. You could see the checks in the scripts. That is why they needed my serial number. In fact that firmware fixed some issues I had with the TV simply because the scripts became better at setting parameters correctly, but caused other problems by setting others now incorrectly.
It is a shame because my family had bought Westinghouse large appliances many years ago and they were very good. I also had some good experiences with Westinghouse computer monitors a few years back. It is a shame how bad their electronics and support people have become.
I just realized that I did not notice the allegations of legal boilerplate modifications that Bruce raised. I wish I could see what he means without spending time investigating it myself. We all learn early on to never touch those files and comments in headers and source code without the permission of a lawyer first unless we are simply adding the current year to the (c) line. That is very bad if that had been mucked with in unscrupulous ways, but there are lots of innocent changes that can be made. Without seeing exactly what Bruce means I don't want to speculate.
Bruce I had a very bad experience regarding the Westinghouse firmware. It was not like how you put it where a company like Sony can put up links to tar balls of source code. Westinghouse did go out of their way to keep me from getting the source code. When I tried to get the source code from them and even provided my serial number for the TV I had purchased, they claimed that there was no source code and no open source code was used. Finally I was able to get a firmware update from Westinghouse. Extracting it and poking around inside it was abundantly clear that busybox and other projects had been used. One was not GPL-like, basically only had in the terms that the software simply needed to be mentioned in the manual. It was omitted from the manualm there was a section listing trademarks and what-not of other products. That is how atrocious Westinghouse was. I returned the TV and decided to never purchase Westinghouse products again. I can easily believe that Westinghouse had dragged its feet for a very long time and did nothing. I am sorry that you are having trouble in your day to day work based on this, but enough is enough when it comes to Westinghouse in particular.
Slashdot Mirror
Huh? Back in the early '80s to mid '90s Toyota was all STAR, extremely proprietary. At the same time GM was simple which became OBD. Ford was all analog (think +/-10V and ADCs) and then went to a simple multiplexed scheme. The only 'standard' was the European makes that used BOSCH as the OEM, since they were all similar (even the connectors).
No the downfall of quality of Toyota was simply this. Up until the '70s they were not very good quality. They decided to improve this. Back then the paragon of quality was Mercedes. So Toyota bought a number of W116 chassis models and tore them apart. Then they ridiculously over engineered everything in the same style.
Now they wanted to become the sales leader in the world. They started letting their suppliers do more of the design and bought off the shelf. You could see the beginning of the end when the multicolored bolts disappeared and low quality cheap ones took their place in the late '90s.
I think you have not scene many car accident scenes. It is often hard to tell what could have happened based on where the cars are after the accident. There does tend to be a lot of chaotic behavior.
They also tend to be in BCD.
What if your chosen password is in fact all caps? Is that a stupid error message then?
Does Toyota even sell any manual cars anymore? Any manual cars that would be a hoot to heel-toe at all?
The chopping off the bottom 4cm is a bad sign. They are not supposed to do this last I heard. It seems to me that they have taken a shortcut for inserting the shim. The service bulletin instructs them to remove the pedal assembly in order to insert the shim. By removing the bottom of the gas pedal they have room to wedge that shim in there without the laborious process of removing and reinstalling it. Also there is more risk that they can get grim in there then (though in the tech is supposed to wipe the outside yet not use compressed air to minimize risk of getting dirt inside).
Also if you have a Camry it is possible that you have a Denso pedal assembly that did not need the shim if I recall correctly. Maybe there is bulletin that is different for those that I am not aware of.
If I were you I would take your car to another Toyota service and have them look at it. Then if they say that is unusual, they should contact Toyota in order to for Toyota to authorize the replacement of your gas pedal assembly. They are supposed to measure pedal travel on a workbench, I really wonder why they chopped off the bottom of yours maybe it was very bad? If I am wrong then you will have had any concerns addressed.
Also the floor mat is a new one with restraints, not that they lopped off chunks of your old one and held it down with something like zip ties, right?
Or the hand brake especially if you have a manual and only two feet.
Seriously they are going to have to have something like the brake is depressed by at least so much say 75% for at least a certain duration say a second for this to kick in. Otherwise how would all the Toyota drivers that I see who rest their left foot on the brake get anywhere?
Thank you very much. It seems that your toolchain aligns structs in the natural way that X86, SPARC, and PPC do. That's great! I guess it assumes you have load and store word that work right. What toolchain and version are you using?
I had to port old code on another occasion that assumed everything other than char and unsigned char was aligned on 2-bytes, that was annoying as well. That's probably what you have on your hands as well. I feel your pain.
Again what I did is I compiled (this time everything since the PPC was SO much faster than the 8088) with that -fpack-struct option and added the xyz_padN members where needed. But first I needed to change all the int, unsigned, unsigned int, to int16_t and uint16_t, and similarly for other types. And then I had all the byte order assumptions to deal with, joy.
Again thanks for the info about natural alignment becoming the norm on newer ARM cores.
Yeah I used gcc cross compiler, it was installed as ccarm when I did ARM stuff, I just used cc as a generic term for "C Compiler."
I'm waiting eagerly since I had SO MUCH network code that did not work right due to the extra padding of shorts in structures to make such structures always 32-bit aligned. I would send and receive using sizeof and so many things would end-up having extra 2 bytes of padding here and there being not at all what I expected at first and of course not working between ASM, X86, and SPARC versions.
Back then I think I could only apply the packed attribute to an entire structure not individual members and these were header files I had not written. I ended-up putting the troublesome functions in seperate C files and compiled them with -fpack-struct or some such option and I put explicit int8_t xyz_padN (N = 0, 1, 2, ...) members in them so things would line-up correctly for ARM packed structs and other archs that were compiled without the option. It was a true PITA with lots of use of cscope.
Could you do this for me:
psize.c:
typedef struct {
unsigned char a;
unsigned short b;
unsigned short c;
} pstruct;
int psize = sizeof (pstruct);
$ cc -c foo.o
And then dump out psize to see what it is. My guess is it will be 8 instead of 6, but that was since my tool chain did not assume ldhw. If I put the packed attribute on member c, then it would be 6, but then the code would have many ldb instructions.
So maybe I am dating myself, is it now common for tool chains to simply assume ldhw is there and no longer align to 32-bits in such cases like above? (ie there would be only one byte of padding after member a.) Also I used to get a useful rotation if I had the bits set to little endian and not to trap on misaligned access. Is that now no longer the case?
For example if I had this at address zero (for simplicity sake):
01234567 89abcdef
and I loaded this:
long v = *((long *)2);
Then v would be 0x23016745 if memory serves. Now that would be 0xab896745?
So I looked a bit and I don't see anything new in cortex that allows to remove this traditional ARM padding.
Does Cortex still behave like this?
You have a struct { int8_t a; int16_t b; int16_t c; }
It will get layed-out on PPC, SPARC, and X86 like so:
a0bbcc
Will it get laid-out in ARM like so?
a0bbcc00
That's how things were often configured in ARM toolchains because in this way the same sequence of instructions can be used to access an array of such structures, not a different sequence for the ones that are aligned on 32-bits and those that are not. Do you loose the useful rotations with misaligned loads with Cortex then?
The strict alignment is already there in portable code since on PPC floats and doubles (and vector types) need to be aligned properly and on SPARC every type needs to be. But what I described above is a different wrinkle about how things get padded that can and does trip-up coders since they are new to it.
Everyone mentions ZFS and Dtrace, I will really miss mdb if solaris ever goes away. mdb is the single best debugger ever created. I have shell scripts that use truss to stop on an bug in closed source code, then use mdb to change some registers, and then use prun to carry-on. That completely ignores all the useful dcmds too.
to get sizes that fit from different companies
There are in Miami and near Madison Wisconsin. They are both very nice for sun bathing and bathing, though recently the there have been young people drinking and being stupid in Wisconsin, and the number of 'prairie dogs' (single males standing staring) are starting to get high in Miami. So in Wisconsin stay in the more crowded areas and in Miami either be in the more gay areas in the very north or the topless areas south.
There are other beaches, but some of them are not officially nude and others are just not pleasant due to being rocky or windy. Those two are very nice.
Thanks, but change it like so:
#!/bin/sh
exec mplayer -autosync 30 -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all "$@"
No actually the same problem exists in cap and trade. There has to be an honest way to count how much greenhouse gasses a company emitted into the atmosphere in a year and how many tons of CO2 is that equivalent to.
Rather than CAT, why not simply tax the company that removes the material from the earth. It's pretty easy to know how many tons of coal a company mined in a year as it simple to know how many gallons of crude were pumped. Now every other company picks that up as an increased cost along the way.
Those taxes collected can then be simply given as tax rebates to tax payers to partially offset the costs associated with global warming and the increased costs of goods and services. Or a government could loan it towards emissions reduction programs, largely in the developing world, with attractive long term returns.
Now that seems efficient to me.
There is one more mechanism, the one used most often. For counties that signed on to Kyoto the certificates are managed by the UN and traded in a primary market largely in London (as well as the large secondary market now as well). The vast majority of current certificates in these markets tend to be for projects in a developing country. What happens is some company (usually not the carbon emitter itself) proposes a plan to a UN agency that basically says that right now some company in Brazil or where ever is emitting the equivalent of so many tons of CO2 per year. If the proposing company can raise $X it has a plan to over Y years (say 10) reduce the tons of CO2 emitted per year by that Brazilian company by Z. Then the UN grants the certificates, and they get sold on the London market. Then they get traded in the secondary markets. So now the companies that hold these certificates can not worry about what ever number of tons of CO2 it is that they bought. The company that issued the approved certificates is now supposed to invest that money into the CO2 reduction project. Seems great but what are the problems?
In practice what has been happening is that there are all the derivatives markets now on all of that paper. So the companies that have the proposed projects only use a fraction of the money on the actual projects themselves, rather they invest most of that on futures for that CO2 and whatnot in order to hedge and hopefully profit in their investments in the derivatives they buy, sell, and exercise.
So does in fact the Brazilian company reduce CO2 emissions in 10 years by Z tons per year? Who knows what will happen, but in the meantime the companies that bought the certificates were able to pollute above their limits. Also all the people involved in the huge markets could have been making very good returns. These people are not likely to police themselves well when the Brazilian company two years later has reduced it C02 emissions by Z/20 thanks to the projects and then goes and sells its credits under shell company shenanigans likely on the secondary poorly regulated market.
The tax on the other hand only has the issue of making sure that CO2 is counted correctly. The government does not even need to use those taxes to fund CO2 reduction programs or anything of the sort. It could simple accept that due to such taxes costs will increase and it could simply distribute them to the taxpayers to somewhat offset that. Then there will only be genuine cost vs time to profit thinking by emitters.
The cap and trade scheme creates some new markets that are larger than any other. It is a boondoggle for investment firms and banks. A tax would not create that. To some that is a positive or negative aspect, but it lends itself to performing very poorly to actually reduce greenhouse gas emissions if not regulated well. It also lends itself to very disruptive speculation that effects energy and ultimately all costs without any of the offset from a tax rebate program.
That said there have been some markets that have in fact been well regulated, so it can be done, but it is not in this case.
Hmmm... Doom was okay on a 33MHz 486DX with 128KB of ecache for single player (stayed above 15 FPS), but for network death match with DEC tulip based ISA NICs using thin coax it would lag and play at 10-12 FPS on that box. The 50MHz 486DX2 and 75MHz 486DX4 did okay. Also there was a 40MHz 386 with a 3COM NIC ISA card that could hold it's own, it did have a Paradise 16-bit ISA SVGA card, the others were Trident and Cirrus Logic, and it did not lag but the frame rate was in the 10-12 FPS range too in deathmatch. All from memory, but man did I not like being stuck with that 33MHz 486.
Sorry that is NOT to spec for NTSC DVD. About the only HxW issue I ever see in testing is that some NTSC DVD players do not display the half height (240) format properly. Usually the image is squished on the top half of the TV. Fortunately VCD was never popular in NA so it is very rare to encounter a DVD that uses VCD-ish MPEG2 video.
Personally I waited and bought the first Panasonic DVD player that did not have any bugs. All previous players from every other vendor had audio, subtitle, VM, and chroma filter issues. That $800 DVD player was the first that really worked with everything. It still works. To this day I run into DVDs that do not work right is some of my other cheap DVD players.
Things that will be useful from math for the practical programmer:
combinatorics
linear algebra
analysis and differential equations
Get as much of those as you can, if they get too hard stop.
Some times statistics courses are best for the combinatorics stuff. You will run into problems that are shuffling things around efficiently, that is where that is useful. Some of the graph theory stuff though may not come from the lower numbered statistics courses though, but you should get enough of that from CS courses. The statistics will give you background for things such as RMSE that come-up in practical coding.
The linear algebra and differential equations often come from math courses targeted towards engineering and physics students. Basically any hard problem that is solved by approximation comes down to an algorithm that is essentially a bunch of linear algebra. Then in many practical areas you need knowledge of things like FFT, PID, etc and the analysis as apposed to discrete math helps there. For a lot of these things if you just have enough knowledge so that you can understand some article, papers, and docs, then it is much easier to use libraries that others have written. That is why you should not fret if too much if the math gets too hard.
Other than that you should get enough abstract algebra and other discrete math from your CS courses. Along the same lines, you should stay away from geometry, it tends to be abstract algebra in disguise, and algorithms courses will have what you may have wanted presented in a way that is useful for programming. Logic is another area that is not very applicable to the practical programmer. You should get enough in some CS courses and some proofs that use applicable techniques there as well as in the combinatorics.
That said if you want to pursue CS, then all the above is VERY poor advice. Then you need as much logic and math as possible. You should love it too.
Somebody mod that up. That is an awesome rant of the best sort, one with experience, opinions, technical details, and examples.
I use SCCS to this day. I like it very much for situations where I am working on some files in SVN or CVS and I am still experimenting. So that I can easily go back when things do not work-out I use sccs edit and delget before I try something new, the way I might have copied to a foo.c.bak or foo.c.3 without SCCS. Then I just cvs or svn commit that dir when I have some good code.
That's largely because of the warts in CVS and SVN though.
That is true. It was evidently clear from the initrd image that this was tweaked reference board hardware. The frustrating thing was that identical model numbers used different components that used different versions of firmware. It appeared that the firmware update I got had support for more TVs, ie some of the ones made earlier, but not all others. You could see the checks in the scripts. That is why they needed my serial number. In fact that firmware fixed some issues I had with the TV simply because the scripts became better at setting parameters correctly, but caused other problems by setting others now incorrectly.
It is a shame because my family had bought Westinghouse large appliances many years ago and they were very good. I also had some good experiences with Westinghouse computer monitors a few years back. It is a shame how bad their electronics and support people have become.
I just realized that I did not notice the allegations of legal boilerplate modifications that Bruce raised. I wish I could see what he means without spending time investigating it myself. We all learn early on to never touch those files and comments in headers and source code without the permission of a lawyer first unless we are simply adding the current year to the (c) line. That is very bad if that had been mucked with in unscrupulous ways, but there are lots of innocent changes that can be made. Without seeing exactly what Bruce means I don't want to speculate.
Bruce I had a very bad experience regarding the Westinghouse firmware. It was not like how you put it where a company like Sony can put up links to tar balls of source code. Westinghouse did go out of their way to keep me from getting the source code. When I tried to get the source code from them and even provided my serial number for the TV I had purchased, they claimed that there was no source code and no open source code was used. Finally I was able to get a firmware update from Westinghouse. Extracting it and poking around inside it was abundantly clear that busybox and other projects had been used. One was not GPL-like, basically only had in the terms that the software simply needed to be mentioned in the manual. It was omitted from the manualm there was a section listing trademarks and what-not of other products. That is how atrocious Westinghouse was. I returned the TV and decided to never purchase Westinghouse products again. I can easily believe that Westinghouse had dragged its feet for a very long time and did nothing. I am sorry that you are having trouble in your day to day work based on this, but enough is enough when it comes to Westinghouse in particular.