Actually, most hosting companies I've dealt with use PHP as a CGI, not mod_php, so they must have the/usr/bin/php someplace, but they may not make it available to you that way (they probably don't give you shell access anyway).
I thought PHP, like Perl, got most of its speed when run as mod_php (like mod_perl) -- I thought a lot of the overhead was loading up the interpreter for every script access? Have I really missed something here?
Actually, it's not terribly new, afaik. I was using it a couple years ago at least, so I know it's not 'new'. I'm not sure if it was available like that in PHP2, but from mid versions of 3 on I can attest that it's been like that.
Hmmm.. I remember reading about having to do some hoop-jumping to get it to run as CGI. I could be mistaken though. I appreciate your response and maybe in the future I'll take another look at PHP.
Agreed, but then there lies the question of actually knowing what your internals are like, and as with an OpenSource based system versus closed source binaries, you have that flexibility to fix, change things on your own.
Exactly. If you don't have an knowledge to debug the Linux kernel then it really isn't all that advantageous to use it over anthing else, unless you consider the ability to whinge on a newsgroup about the problem and hope someone fixes it for you.:-)
But, as you said, if you've got the know-how you can at least attempt to fix it on your own. And if you're designing embedded systems chances are you have enough knowledge, gumption and/or instinctive knowledge to do it anyway. And therein lies the Open Source magic bullet.
No offense, but you seem to have a fairly loose understanding of PHP at best.
This may be; I haven't seriously looked at the language in over a year now.
If your programming
is good, modular, and loosely-connected, your
script will not care whether it's running on the
web or on the command line.
Okay; I've got Perl installed on all systems I work on. PHP is (was) installed only where it made real sense: on the webservers. Why would I write Perl modules to do some fairly generic work and then rewrite them in PHP to take advantage of them for the webservers? Or why would I write a PHP class which did something great only to find out later that I can use it on another system without PHP and have to rewrite it in Perl? I simply settled on one scripting language which I feel is more superior.
And I'm not sure where you got the idea that perl doesn't use an interpreter...
Actually I didn't say that. As I wrote to another person who replied, #!/usr/bin/php is a fairly new development IIRC. Before that you had to use phpcgi or some damn thing which I'd written off as a hack to make PHP more useful outside of webspace. If it indeed has gotten a generic interpreter that's great. In my eyes I've crossed that bridge. It's too little, too late. The languages are too similar to me to warrant "perfecting" both.
Don't get me wrong, I like perl as much
as the next guy...but this holy war assumed-condescension is silly.
Agreed. PHP makes some things easy that Perl doesn't either. And the general syntax is cleaner IMO as well (I come from a C background). But this entire article seemed to be the breeding grounds for a holy war and it was late, so I thought I'd fan the flames a bit.:-)
The DBI argument gets more specious by the day, too. Check out PEAR. Or PHPLib. Or Metabase.
I can create a connection, run commands and get results generically with DBI. Yes there are vendor-specific extensions, but the base calls are the same. A year ago PHP did not have this. There were pg_* calls for Postgres, mysql_* calls for MySQL, msql_* calls for mSQL, etc. Yes there were generic ODBC drivers but hardly anyone uses them if they're working on a high(er) performance system because vendor ODBC drivers are notoriously slow. DBI fixed that.
There are lots of valid reasons one could give to prefer perl over PHP, or PHP over perl, or emacs over vi, or milkshakes over spaghetti...but what you've written are not among them.
I don't see how my post didn't give any valid reasons. I stated my own reasons and here I've backed them up further.
As I'd said, I started out as a PHP guy. Loved it. Then I started wondering why I was learning two languages that were very similar, did pretty much the same jobs but one was more targetted to web apps. So after some careful consideration and a few posts to various Ask Slashdot's I made my choice. And I really don't miss PHP, which indicates to me that it was a good choice to settle on one scripting language, and (IMO) the more versatile and powerful one. That's not meant as a flame against PHP; it's just a direct observation on my part. I've not been able to prove that PHP is significantly easier, faster or different to warrant learning it.
It is not as widely-distributed on the systems I work on as PHP. And unless I'm mistaken, #!/usr/bin/php is a fairly recent thing; before the generic interpreter was available you had to use phpcgi or some damn thing.
Just wondering how do you remove big SMT chips without damaging them?
Same idea - heat up all the legs. If the chip doesn't have many legs I can usually do it with a broad-tip iron but if there are many legs (like that 204 pin PQFP you need to use a heat gun and be extraordinarily careful. I usually just scrap the part if it's got a lot of legs (they're almost exclusively removed only if the chip is bad anyway) -- cut the legs with an X-acto knife and remove the pins a few at a time.
The majority of your post is complete nonsense. I tried to comment on it but it's like trying to talk electronics to my wife. However your second paragraph I can comment on:
As far as embedded linux goes, the uses that i've seen for it make me want to use it as often as possible, especially with the linux embedded bios chips that i've read about allowing for faster workstation booting, as well as smoother allocation of resources on linux machines, which all-in-all is something I think all of us would like.
I've read a lot about the OpenBIOS project and had subscribed to the mailing list for a while before I came to the conclusion that there just is zero need for such a thing. Having a BIOS which can access a network via BOOTP/TFTP is all you need. If you need absolutely instant-on then you're entire OS will be in flash; not just some 32-bit BIOS implementation.
Indeed it would be a nice idea, however if I'm not mistaken, these embedded Linux systems won't be open sourced, so tweaking code is out of the question;)
The embedded sytems don't have to be open sourced. If I'm selling widgets and there's a design flaw, I don't expect the user to fix it for me. In the same vein, if there's a driver bug or even a core flaw in Linux it's not my customer's problem. It's mine. Having the source and being able to contribute a patch back so that others won't be bitten is a good thing. It's been a while but I don't recall being able to do that with QNX.
I guess he's never heard of/used QNX, ChorusOS Nucleus, or ThreadX.
Aside from QNX, I've never heard of the others and I do embedded systems design for a living.
I did however like the gadgets, but taking a look at the last week, with all the Linux related companies going to the dogs, and 4 distributions going "kaput" within less than 6 months time, I would be looking at other alternatives to Linux, especially if my business were going to depend on them.
As another poster mentioned, what exactly do linux companies have to do with embedded linux? RedHat could die tomorrow. Big whoop. The beauty of the core system being totally open source is that if it's THAT important to you, you can continue where they left off. Many embedded Linux kernels are based off of the base Linux system or uClinux with or without the hard realtime scheduling patches.
If your core system is working just fine and the company supporting it dies, did you really lose anything? If a user discovers a nasty-ass bug that is traced to a core function or otherwise is a problem with the Linux core... you do have the source. You can fix it on your own. Waiting for a vendor to fix a problem is as much a pain in the ass as the customer screaming about the bug in the first place.
Perl. Why learn two languages when one does 99.9% of it without breaking a sweat? Seriously. PHP has umpteen number of DB interfaces. Perl has DBI. No matter what you talk to it's all DBI and it's fast. Regexps? OO? Parsing? PHP and Perl both have them but why write your modules once in PHP and then have to redo them again in Perl just because you want to use it outside of the web?
Yeah I know about the PHP interpreter but that's just plain old hokey. And to think I was once a really avid PHP guy. If all you're doing is web, PHP is really sweet. But really when you think of it you have other things to do too... parsing logs, reformatting, search and replace... things that get done on a daily basis and are beyond the scope of "just the web". Write the module once, write it good and use it in all situations!
Wirewrap was nasty nasty stuff to work with. Anything past a low to low-mid density board was hell when you had to think of doing modifications. It's still widely used in telecom (breakout panels et al) but I'm glad it's disappearing from the general electronics scene.
Surface mount is not hard to do by hand. Hell I still regularly solder 204 pin PQFP parts by hand and achieve "just about as good" results as professionally soldered. Hell I prefer soldering surface mount boards. Just don't start putting 0402 parts on the board! But SOT-23, 1206, PLCC, PQFP and even TS(S)OP packages aren't a problem unless I've had too much caffeine. And modifying or replacing SMT components is far simpler and less harsh on the board than through-hole parts.
What I find really disappointing is how fast the hobbyiest market is shrinking. Generic discretes are harder and harder to come by and the young'uns just want to play with software for the most part. CPLDs, FPGAs and ASICs remove most of the reverse-engineer-ability from larger designs and even the $9.99 consumer market has been replaced with (code protected) microcontrollers, epoxy-covered chip dice, or both.
On a side note, I'm pretty sure I read somewhere that pg_dump uses MVCC to take a snapshot of the database when you run it. Correct me if I'm wrong, but wouldn't that imply that it can be run hot with no ill effects...?
I'm not too sure whether it would be able to be done with no ill effects... you could probably get away with it but it's almost guaranteed that the time you need the data back is the time that it didn't work.:-) The postgres documentation and mailing lists seem to suggest that even if it is possible right now that it is definately NOT reccomended.
It would be very nice to be able to tar -czf/dev/tape/dev/postgressdata to get a live snapshot... no bogus backup programs, nada.. just a device which when read would give a postgres-sanctioned copy of the database and when written would restore to that state.
I don't know about you, but I try to keep by database as separated as possible from the application/business logic.
This is fine for some, maybe even most instances but when you are working on high performance and/or large applications it becomes necessary to more tightly integrate with the datastore and let the database do the hard work. Hell even letting the database do things like sorting and ordering (which does not rely on integration) output tends to be faster and more efficient of resources than pulling it into application-space and doing it there.
This is especially true with large tables when you only want a certain subset (top 10 selling items, top 50 support issues, etc. -- you don't pull in all 10000 (100k, 1M, whatever) rows into a Perl script or C program and strip off the ones you want; that's ludicrous. You ask the DB for what you want via cursors)
Sticking bunches of code in the database via stored procedures violates this; the result is my app is now tied to the database. That can be quite a pain to upgrade.
Moving from Postgres to Sybase or Oracle when stored procedures and other goodies are present is trickier, yes. But the performance you get with stored procedures not only allows you to forego the upgrade for (much) longer but also tends to out-and-out work better.
Why, then, is it seen as an advantage to perform application logic in the database?
As mentioned above: performance. Also more efficent use of resources (memory, cached storage, processor utilization, etc.) (e.g. the database already knows where things are, has them hashed, indexed and possibly (pre-)cached and ready for your app.
You don't want to put a lot of complex and "proprietary" (in the application sense -- things which aren't used to maintain database integrity or get results out faster) code in the stored procedure. You do, however, want to put complex selects, inserts and updates into the stored procedures and call them from application space as a higher-level command. Or have the database call them automatically to keep data integrity via triggers.
e.g. a large insurance-type application won't put the actual detailed calcuations for premiums into database stored procedures but you probably would put a complex function which updated the premium matrices on each payout based on the data which is entered for every payout. In my mind that doesn't violate any design policy; it in fact helps to enforce database integrity since it doesn't rely on an outside application to keep the premium matrices up to date. It's done inside the database with a trigger and at the exact instant that each payout is entered.
For what it's worth, I agree with you in keeping code to run the application the hell out of the database, but I do also see the value in integrating specific functions right into the database. It's a bit of a trade-off for upgradability but really if you're specifying a system you don't WANT to upgrade it for as long as possible and you'll quote hardware / software which will do the job right the first time around and with a certain amount of anticipated growth.
I've been keeping my eye on Ultra WideBand for a while now; it has very surprising uses in positioning, communication and measurement. There's even a working group which tries to keep tabs on the entire area.
Years ago I heard about time-domain. I don't work for them but when I first heard of them I thought it was vaporware. I'm kind of sorry I didn't take them seriously the first time around.
postgres has a number of very nice features, like stored functions and transactions.
Don't forget cursors. Since they require transactions I suppose you've included them though.
There's nothing nicer than being able to ask the database for a top ten list or otherwise get a subset of data from a large table without pulling the entire table into Perl. Combine that with the stored functions and you can do some very powerful things within the database... which is actually exactly what databases are so popular for.
Just about anyone can store things in a flat file and hash it to get fast search results. It's the ability to manipulate data that makes a database powerful, not just its raw speed on simple selects.
You're not understanding the issue here. There are people contributing PPC patches and Linus is rejecting them. IIRC, he was saying the patches were too big. He wanted a number of smaller patches instead of one big patch.
What makes the PPC guys think that they can get big patches by Linus when he rejects big patches from everyone else too? Does their shit smell better or something?
If that's the only issue, I see nothing wrong. Linus is holding everyone to the same set of standards.
Then you own at the very least one PPC CPU already. the OBD 2 specification (on-board diagnostics v2) calls for a PPC platform, and ALL car manufacturers are using it. Automatic tranmission? there's another one. Digital dash? theres one more. Anti-lock brakes? there's at *LEAST* 2 more PPCs in that computer.
I seriously doubt there is a PPC running my digital dash, transmission or even engine for that matter. The PowerPC is one fuck of a lot of power. I would believe that a 68HC-class 8-bitter were running the display, maybe another for the transmission and a 16-bit CPU running the engine timing and so on.
Hell I would imagine that the ColdFire processor by Motorola would have enough juice to run the car, transmission and dash. But I digress -- DSPs would run the engine and brakes. Not a PPC.
We had several linux boxen in CS, which were rebooted after 319 days for a kernel upgrade - you know that big step between 2.0.x and 2.4?
That's nothing -- Try doing the old a.out to ELF conversion by hand (this was around kernel version 1.2.13 I think)... easily 10x harder to do than libc5 to libc6, but MAN did I learn a lot... like the value of statically linked ln.:-)
Power a three-phase motor via a six-scr power stack. When the SCRs are fully phased-on (i.e. triggered at 0 degrees through 180) the motor will have full line power, minus the volt or so the SCRs drop the line. By "reduce the phase angle" I mean to start phasing back the SCRs... instead of turning on at 0 degrees, turn them on at 45 degrees (3/4 of the half-sine wave) -- If the motor is driving something like a pump or a high inertia load the current will rise quite a bit.
If the motor were supplying power back to the mains your current would drop, as the sign of the real power component went through zero (then it would rise again). If you run the motor backwards the effective inductance of the motor drops and your reactive current goes way up; your slip ratio is climbing beyond 1 and you're probably way down the tail of the real-power curve
We're not running backwards; the load is turning the motor in the same direction it was originally going (high inertia load) or trying to turn it in the opposite direction (think of a mile of water trying to push back against the pump). In the second case (where I am more familliar) you are moving back up the speed/torque curve and, in most instances the current will rise and rise until you just don't have the voltage there anymore (as you are phasing back and turning off the power to the motor as you decel).
Depends on the what you have to filter, doesn't it? Depending on the harmonic output of the inverter, I could see the filter being smaller than a car-alternator hash filter.
I agree but if you're using PWM waveforms to generate a sinusoidal current waveform you are going to have very steep edges (as you switch from +bus to gnd and back) and the only way to get nice steep edges is to have lots of harmonic content. Now Don Lancaster is pushing something called Magic Sinewaves which are just PWM waveforms which are engineered to reduce or eliminate specific harmonics. From what I have read of them (he's been into them for a few years now), they look really interesting for fixed amplitude waveforms, like in UPSes and the like. Hell some of them are even delta-friendly.
A 130 volt MOV connected to a 120 VAC (RMS) outlet is going to blow within a few tenths of a second.
Actually it won't blow that fast. I'm hunting around for a power supply I can rip apart so I can cross the part to show you that I'm right but at this time I can't. Maybe later tonight I'll get back to you; depends on what the kids get into.:-)
Sorry, wrong. An induction motor will only generate power if it is turning faster than synchronous speed.
Hmmm, I guess that's why we have the current go through the roof when you're driving a pump and go to reduce phase angle, right? (I suppose you could say that when you reduce the phase angle you're changing the synchronous speed...) In the case of driving a motor with the UPS you can cause the bus to rise if you're in a high inertia situation. (pushing a heavy piston up and then gravity assists it in falling, this will push you past your synchronous speed as well.)
I can't speak for the designers of all UPS's, but any unit with either a pi-network or L-network (inductor input) output filter is going to soak up those spikes before they leave the box.
Perhaps it's because I'm in large industrial controls but would a 700W filter not be rather large and bulky?
*Unless it is a single-phase motor and you get it up to the speed where the start winding disconnects. If that happens, a single-phase induction motor will happily run backwards.
We (Benshaw) can get a three phase motor to rotate backwards with a six-SCR starter through a cycloconvertor type of firing algorithm. (actually the standard set of software will do 7 and 14% of full speed forward and 20% reverse.) We sell this feature quite a bit for bucket inspections and positioning as the client usually doesn't have need for a full-blown drive and doesn't want to pay 2.5x the price for one.
and am running an AT power supply off a Modified-Sine Wave. There has been no problem what so ever.
Squarewaves don't hurt transformers and equipment. They stress them. Your 120VAC 60Hz transformer was made to work at 60Hz. Throw a squarewave at it and you'll increase its temperature as it is now having to deal with 180Hz, 300Hz, 420Hz... The 60Hz transformer is not efficient at these frequencies and it will heat up due to eddy currents in the laminations and so on.
The equipment on the other side won't see much since the transformer is blocking most if not all of these nasties. However that transformer is now likely running out of spec.
If you want to be nice to your equipment and are running it off of a stepped-wave inverter, just take a pair of 120V-24V (or whatever) transformers which are larger than they need be (rule of thumb: if you need 20VA make these 30 or 40VA each) and hook them up back-to-back. i.e. your inverter output goes to the 120V side of the first transformer. Now the 24V side goes to the 24V side of the other, and the 120V side of the second transformer goes to your equipment. You've now just made an isolation transformer and, in addition to isolating the equipment from your electrical system (ground it yet!), you've also made a very handy (but inefficient as hell) 60Hz filter. Since the transformers are oversized you won't run into much trouble. Keep an eye on the temp (run the computer at full tilt for a number of hours to get the heat rise on the isolation transformer) and add a fan to them if needed.
To summarize: Squarewaves do affect equipment not designed for them.
Unless, of course, you've got some special application in mind that doesn't need much current, like keeping an ISDN line up during short blackouts or somesuch.
Actually telco equipment is designed to run off of -48VDC for precisely this reason. They can use the mains to float charge the batteries and if power goes, oh well.:-)
I've written a fairly detailled comment to both you and fwc here. Instead of copying and pasting it again, I've just made a link.
Looking forward to comments.
Most inverters spit out a sinusoid-like CURRENT waveform because they have a large inductor or transformer to smooth out the current (inductors oppose fast current changes). The industry hasn't made linear-mode UPSes for at least a decade now, as the losses are too high.
Motors don't harm UPSes, UPSes harm motors. (more on this later.) A UPS is essentially a cheap VFD (Variable Frequency Drive). Unlike DC motors, you can't get full torque out of an AC motor by just reducing the voltage. The frequency and voltage must be kept in a specific ratio in order to keep the torque characteristics of the motor.
Unfortunately for UPSes, the voltage waveform they spit out is more or less a nasty-ass chopped up PWM waveform. Bad for anything, really. With motors (and most inductors) you will end up breaking down the insulation on the first few windings of the stator (in the case of a motor). That's why motor manufacturers (I'm talking 3-phase here) use "inverter-grade" wire; the insulation is better and can withstand this nasty voltage spiking.
And no, the more expensive UPSes still spit out a nasty-ass voltage wave form. You are paying for either a) a higher switching frequency, b) better PWM control (meaning a more balanced waveform), c) more stages (instead of just on-off, on, 1/2way and full) and/or c) heavy inductors or output transformers to smooth out the current waveform. I haven't seen a commercial step-like UPS in ages (too many components for not much advantage). Stick a scope probe across your high-end UPS; it's still got a nasty voltage waveform but chances are it's giving you a truer (closer to sine) current output than your $100 special.
Most PCs come with cheap-ass switchmode power supplies. There are MOVs in almost all equipment. Unfortunately most suppliers use 130V MOVs. The peak-to-peak voltage on standard North American outlets is about 170VAC (120VRMS is 170V p-p) -- those MOVs eventually fail because they're turning on at the peaks of each cycle for the briefest of moments. Sketch out a sinewave with 84V peaks; the amount of time you're over 60 degrees is only a few tens of degrees. Depending on the construction of the power supply you'll either blow the shit out of the MOV or the internal fuse eventually. I've fixed countless computer power supplies by replacing the MOV and/or fuse.
What's that got to do with inverters and UPSes? Simple, really: the PWM voltage output has lots of nice sharp edges and causes all kinds of ringing in any length of cable. It can help lead to premature failure of power supplies but when it does fail it looks no different than a normal equipment failure. Yeah there's a $25k replacement value given but that's only from lightning strike or power surge on the incoming side of the UPS. Read the fine print; it does not cover failures as I've described.
The only time that an AC motor will cause grief to a UPS is if you're powering it and your load is actually driving the motor; i.e. you're using a motor to power an uphill conveyor and the load on the conveyor gets to great as to start moving the belt downhill and drive the motor. This causes the motor to generate instead of.. uh.. "motorate" and raises the bus voltage on your poor UPS which was NOT designed to do so. This usually overvoltages the caps and as I've seen many times in our power lab, things come apart.
Slashdot Mirror
Actually, most hosting companies I've dealt with use PHP as a CGI, not mod_php, so they must have the /usr/bin/php someplace, but they may not make it available to you that way (they probably don't give you shell access anyway).
I thought PHP, like Perl, got most of its speed when run as mod_php (like mod_perl) -- I thought a lot of the overhead was loading up the interpreter for every script access? Have I really missed something here?
Actually, it's not terribly new, afaik. I was using it a couple years ago at least, so I know it's not 'new'. I'm not sure if it was available like that in PHP2, but from mid versions of 3 on I can attest that it's been like that.
Hmmm.. I remember reading about having to do some hoop-jumping to get it to run as CGI. I could be mistaken though. I appreciate your response and maybe in the future I'll take another look at PHP.
Agreed, but then there lies the question of actually knowing what your internals are like, and as with an OpenSource based system versus closed source binaries, you have that flexibility to fix, change things on your own.
Exactly. If you don't have an knowledge to debug the Linux kernel then it really isn't all that advantageous to use it over anthing else, unless you consider the ability to whinge on a newsgroup about the problem and hope someone fixes it for you. :-)
But, as you said, if you've got the know-how you can at least attempt to fix it on your own. And if you're designing embedded systems chances are you have enough knowledge, gumption and/or instinctive knowledge to do it anyway. And therein lies the Open Source magic bullet.
No offense, but you seem to have a fairly loose understanding of PHP at best.
This may be; I haven't seriously looked at the language in over a year now.
If your programming is good, modular, and loosely-connected, your script will not care whether it's running on the web or on the command line.
Okay; I've got Perl installed on all systems I work on. PHP is (was) installed only where it made real sense: on the webservers. Why would I write Perl modules to do some fairly generic work and then rewrite them in PHP to take advantage of them for the webservers? Or why would I write a PHP class which did something great only to find out later that I can use it on another system without PHP and have to rewrite it in Perl? I simply settled on one scripting language which I feel is more superior.
And I'm not sure where you got the idea that perl doesn't use an interpreter...
Actually I didn't say that. As I wrote to another person who replied, #!/usr/bin/php is a fairly new development IIRC. Before that you had to use phpcgi or some damn thing which I'd written off as a hack to make PHP more useful outside of webspace. If it indeed has gotten a generic interpreter that's great. In my eyes I've crossed that bridge. It's too little, too late. The languages are too similar to me to warrant "perfecting" both.
Don't get me wrong, I like perl as much as the next guy...but this holy war assumed-condescension is silly.
Agreed. PHP makes some things easy that Perl doesn't either. And the general syntax is cleaner IMO as well (I come from a C background). But this entire article seemed to be the breeding grounds for a holy war and it was late, so I thought I'd fan the flames a bit. :-)
The DBI argument gets more specious by the day, too. Check out PEAR. Or PHPLib. Or Metabase.
I can create a connection, run commands and get results generically with DBI. Yes there are vendor-specific extensions, but the base calls are the same. A year ago PHP did not have this. There were pg_* calls for Postgres, mysql_* calls for MySQL, msql_* calls for mSQL, etc. Yes there were generic ODBC drivers but hardly anyone uses them if they're working on a high(er) performance system because vendor ODBC drivers are notoriously slow. DBI fixed that.
There are lots of valid reasons one could give to prefer perl over PHP, or PHP over perl, or emacs over vi, or milkshakes over spaghetti...but what you've written are not among them.
I don't see how my post didn't give any valid reasons. I stated my own reasons and here I've backed them up further.
As I'd said, I started out as a PHP guy. Loved it. Then I started wondering why I was learning two languages that were very similar, did pretty much the same jobs but one was more targetted to web apps. So after some careful consideration and a few posts to various Ask Slashdot's I made my choice. And I really don't miss PHP, which indicates to me that it was a good choice to settle on one scripting language, and (IMO) the more versatile and powerful one. That's not meant as a flame against PHP; it's just a direct observation on my part. I've not been able to prove that PHP is significantly easier, faster or different to warrant learning it.
What the hell is wrong with the PHP interpreter?
It is not as widely-distributed on the systems I work on as PHP. And unless I'm mistaken, #!/usr/bin/php is a fairly recent thing; before the generic interpreter was available you had to use phpcgi or some damn thing.
Just wondering how do you remove big SMT chips without damaging them?
Same idea - heat up all the legs. If the chip doesn't have many legs I can usually do it with a broad-tip iron but if there are many legs (like that 204 pin PQFP you need to use a heat gun and be extraordinarily careful. I usually just scrap the part if it's got a lot of legs (they're almost exclusively removed only if the chip is bad anyway) -- cut the legs with an X-acto knife and remove the pins a few at a time.
The majority of your post is complete nonsense. I tried to comment on it but it's like trying to talk electronics to my wife. However your second paragraph I can comment on:
As far as embedded linux goes, the uses that i've seen for it make me want to use it as often as possible, especially with the linux embedded bios chips that i've read about allowing for faster workstation booting, as well as smoother allocation of resources on linux machines, which all-in-all is something I think all of us would like.
I've read a lot about the OpenBIOS project and had subscribed to the mailing list for a while before I came to the conclusion that there just is zero need for such a thing. Having a BIOS which can access a network via BOOTP/TFTP is all you need. If you need absolutely instant-on then you're entire OS will be in flash; not just some 32-bit BIOS implementation.
Indeed it would be a nice idea, however if I'm not mistaken, these embedded Linux systems won't be open sourced, so tweaking code is out of the question ;)
The embedded sytems don't have to be open sourced. If I'm selling widgets and there's a design flaw, I don't expect the user to fix it for me. In the same vein, if there's a driver bug or even a core flaw in Linux it's not my customer's problem. It's mine. Having the source and being able to contribute a patch back so that others won't be bitten is a good thing. It's been a while but I don't recall being able to do that with QNX.
I guess he's never heard of/used QNX, ChorusOS Nucleus, or ThreadX.
Aside from QNX, I've never heard of the others and I do embedded systems design for a living.
I did however like the gadgets, but taking a look at the last week, with all the Linux related companies going to the dogs, and 4 distributions going "kaput" within less than 6 months time, I would be looking at other alternatives to Linux, especially if my business were going to depend on them.
As another poster mentioned, what exactly do linux companies have to do with embedded linux? RedHat could die tomorrow. Big whoop. The beauty of the core system being totally open source is that if it's THAT important to you, you can continue where they left off. Many embedded Linux kernels are based off of the base Linux system or uClinux with or without the hard realtime scheduling patches.
If your core system is working just fine and the company supporting it dies, did you really lose anything? If a user discovers a nasty-ass bug that is traced to a core function or otherwise is a problem with the Linux core... you do have the source. You can fix it on your own. Waiting for a vendor to fix a problem is as much a pain in the ass as the customer screaming about the bug in the first place.
Perl. Why learn two languages when one does 99.9% of it without breaking a sweat? Seriously. PHP has umpteen number of DB interfaces. Perl has DBI. No matter what you talk to it's all DBI and it's fast. Regexps? OO? Parsing? PHP and Perl both have them but why write your modules once in PHP and then have to redo them again in Perl just because you want to use it outside of the web?
Yeah I know about the PHP interpreter but that's just plain old hokey. And to think I was once a really avid PHP guy. If all you're doing is web, PHP is really sweet. But really when you think of it you have other things to do too... parsing logs, reformatting, search and replace... things that get done on a daily basis and are beyond the scope of "just the web". Write the module once, write it good and use it in all situations!
Wirewrap was nasty nasty stuff to work with. Anything past a low to low-mid density board was hell when you had to think of doing modifications. It's still widely used in telecom (breakout panels et al) but I'm glad it's disappearing from the general electronics scene.
Surface mount is not hard to do by hand. Hell I still regularly solder 204 pin PQFP parts by hand and achieve "just about as good" results as professionally soldered. Hell I prefer soldering surface mount boards. Just don't start putting 0402 parts on the board! But SOT-23, 1206, PLCC, PQFP and even TS(S)OP packages aren't a problem unless I've had too much caffeine. And modifying or replacing SMT components is far simpler and less harsh on the board than through-hole parts.
What I find really disappointing is how fast the hobbyiest market is shrinking. Generic discretes are harder and harder to come by and the young'uns just want to play with software for the most part. CPLDs, FPGAs and ASICs remove most of the reverse-engineer-ability from larger designs and even the $9.99 consumer market has been replaced with (code protected) microcontrollers, epoxy-covered chip dice, or both.
On a side note, I'm pretty sure I read somewhere that pg_dump uses MVCC to take a snapshot of the database when you run it. Correct me if I'm wrong, but wouldn't that imply that it can be run hot with no ill effects...?
I'm not too sure whether it would be able to be done with no ill effects... you could probably get away with it but it's almost guaranteed that the time you need the data back is the time that it didn't work. :-) The postgres documentation and mailing lists seem to suggest that even if it is possible right now that it is definately NOT reccomended.
It would be very nice to be able to tar -czf /dev/tape /dev/postgressdata to get a live snapshot... no bogus backup programs, nada.. just a device which when read would give a postgres-sanctioned copy of the database and when written would restore to that state.
Is online backup. Shutting down and using pg_dump just doesn't rock muh world.
In every other respect though I love Postgres. It is a serious RDBMS and should have a spot in Open Source history right up there with Samba.
I don't know about you, but I try to keep by database as separated as possible from the application/business logic.
This is fine for some, maybe even most instances but when you are working on high performance and/or large applications it becomes necessary to more tightly integrate with the datastore and let the database do the hard work. Hell even letting the database do things like sorting and ordering (which does not rely on integration) output tends to be faster and more efficient of resources than pulling it into application-space and doing it there.
This is especially true with large tables when you only want a certain subset (top 10 selling items, top 50 support issues, etc. -- you don't pull in all 10000 (100k, 1M, whatever) rows into a Perl script or C program and strip off the ones you want; that's ludicrous. You ask the DB for what you want via cursors)
Sticking bunches of code in the database via stored procedures violates this; the result is my app is now tied to the database. That can be quite a pain to upgrade.
Moving from Postgres to Sybase or Oracle when stored procedures and other goodies are present is trickier, yes. But the performance you get with stored procedures not only allows you to forego the upgrade for (much) longer but also tends to out-and-out work better.
Why, then, is it seen as an advantage to perform application logic in the database?
As mentioned above: performance. Also more efficent use of resources (memory, cached storage, processor utilization, etc.) (e.g. the database already knows where things are, has them hashed, indexed and possibly (pre-)cached and ready for your app.
You don't want to put a lot of complex and "proprietary" (in the application sense -- things which aren't used to maintain database integrity or get results out faster) code in the stored procedure. You do, however, want to put complex selects, inserts and updates into the stored procedures and call them from application space as a higher-level command. Or have the database call them automatically to keep data integrity via triggers.
For what it's worth, I agree with you in keeping code to run the application the hell out of the database, but I do also see the value in integrating specific functions right into the database. It's a bit of a trade-off for upgradability but really if you're specifying a system you don't WANT to upgrade it for as long as possible and you'll quote hardware / software which will do the job right the first time around and with a certain amount of anticipated growth.
I've been keeping my eye on Ultra WideBand for a while now; it has very surprising uses in positioning, communication and measurement. There's even a working group which tries to keep tabs on the entire area.
Years ago I heard about time-domain. I don't work for them but when I first heard of them I thought it was vaporware. I'm kind of sorry I didn't take them seriously the first time around.
postgres has a number of very nice features, like stored functions and transactions.
Don't forget cursors. Since they require transactions I suppose you've included them though.
There's nothing nicer than being able to ask the database for a top ten list or otherwise get a subset of data from a large table without pulling the entire table into Perl. Combine that with the stored functions and you can do some very powerful things within the database... which is actually exactly what databases are so popular for.
Just about anyone can store things in a flat file and hash it to get fast search results. It's the ability to manipulate data that makes a database powerful, not just its raw speed on simple selects.
You're not understanding the issue here. There are people contributing PPC patches and Linus is rejecting them. IIRC, he was saying the patches were too big. He wanted a number of smaller patches instead of one big patch.
What makes the PPC guys think that they can get big patches by Linus when he rejects big patches from everyone else too? Does their shit smell better or something?
If that's the only issue, I see nothing wrong. Linus is holding everyone to the same set of standards.
Then you own at the very least one PPC CPU already. the OBD 2 specification (on-board diagnostics v2) calls for a PPC platform, and ALL car manufacturers are using it. Automatic tranmission? there's another one. Digital dash? theres one more. Anti-lock brakes? there's at *LEAST* 2 more PPCs in that computer.
I seriously doubt there is a PPC running my digital dash, transmission or even engine for that matter. The PowerPC is one fuck of a lot of power. I would believe that a 68HC-class 8-bitter were running the display, maybe another for the transmission and a 16-bit CPU running the engine timing and so on.
Hell I would imagine that the ColdFire processor by Motorola would have enough juice to run the car, transmission and dash. But I digress -- DSPs would run the engine and brakes. Not a PPC.
We had several linux boxen in CS, which were rebooted after 319 days for a kernel upgrade - you know that big step between 2.0.x and 2.4?
That's nothing -- Try doing the old a.out to ELF conversion by hand (this was around kernel version 1.2.13 I think)... easily 10x harder to do than libc5 to libc6, but MAN did I learn a lot... like the value of statically linked ln. :-)
Explain "reducing phase angle" in English.
Power a three-phase motor via a six-scr power stack. When the SCRs are fully phased-on (i.e. triggered at 0 degrees through 180) the motor will have full line power, minus the volt or so the SCRs drop the line. By "reduce the phase angle" I mean to start phasing back the SCRs... instead of turning on at 0 degrees, turn them on at 45 degrees (3/4 of the half-sine wave) -- If the motor is driving something like a pump or a high inertia load the current will rise quite a bit.
If the motor were supplying power back to the mains your current would drop, as the sign of the real power component went through zero (then it would rise again). If you run the motor backwards the effective inductance of the motor drops and your reactive current goes way up; your slip ratio is climbing beyond 1 and you're probably way down the tail of the real-power curve
We're not running backwards; the load is turning the motor in the same direction it was originally going (high inertia load) or trying to turn it in the opposite direction (think of a mile of water trying to push back against the pump). In the second case (where I am more familliar) you are moving back up the speed/torque curve and, in most instances the current will rise and rise until you just don't have the voltage there anymore (as you are phasing back and turning off the power to the motor as you decel).
Depends on the what you have to filter, doesn't it? Depending on the harmonic output of the inverter, I could see the filter being smaller than a car-alternator hash filter.
I agree but if you're using PWM waveforms to generate a sinusoidal current waveform you are going to have very steep edges (as you switch from +bus to gnd and back) and the only way to get nice steep edges is to have lots of harmonic content. Now Don Lancaster is pushing something called Magic Sinewaves which are just PWM waveforms which are engineered to reduce or eliminate specific harmonics. From what I have read of them (he's been into them for a few years now), they look really interesting for fixed amplitude waveforms, like in UPSes and the like. Hell some of them are even delta-friendly.
A 130 volt MOV connected to a 120 VAC (RMS) outlet is going to blow within a few tenths of a second.
Actually it won't blow that fast. I'm hunting around for a power supply I can rip apart so I can cross the part to show you that I'm right but at this time I can't. Maybe later tonight I'll get back to you; depends on what the kids get into. :-)
Sorry, wrong. An induction motor will only generate power if it is turning faster than synchronous speed.
Hmmm, I guess that's why we have the current go through the roof when you're driving a pump and go to reduce phase angle, right? (I suppose you could say that when you reduce the phase angle you're changing the synchronous speed...) In the case of driving a motor with the UPS you can cause the bus to rise if you're in a high inertia situation. (pushing a heavy piston up and then gravity assists it in falling, this will push you past your synchronous speed as well.)
I can't speak for the designers of all UPS's, but any unit with either a pi-network or L-network (inductor input) output filter is going to soak up those spikes before they leave the box.
Perhaps it's because I'm in large industrial controls but would a 700W filter not be rather large and bulky?
*Unless it is a single-phase motor and you get it up to the speed where the start winding disconnects. If that happens, a single-phase induction motor will happily run backwards.
We (Benshaw) can get a three phase motor to rotate backwards with a six-SCR starter through a cycloconvertor type of firing algorithm. (actually the standard set of software will do 7 and 14% of full speed forward and 20% reverse.) We sell this feature quite a bit for bucket inspections and positioning as the client usually doesn't have need for a full-blown drive and doesn't want to pay 2.5x the price for one.
The article is much sub-Katzian navel-gazing of the lowest order.
Navel-gazing... I like the connotation given by that word combination. Describes some people I know perfectly.
and am running an AT power supply off a Modified-Sine Wave. There has been no problem what so ever.
Squarewaves don't hurt transformers and equipment. They stress them. Your 120VAC 60Hz transformer was made to work at 60Hz. Throw a squarewave at it and you'll increase its temperature as it is now having to deal with 180Hz, 300Hz, 420Hz... The 60Hz transformer is not efficient at these frequencies and it will heat up due to eddy currents in the laminations and so on.
The equipment on the other side won't see much since the transformer is blocking most if not all of these nasties. However that transformer is now likely running out of spec.
If you want to be nice to your equipment and are running it off of a stepped-wave inverter, just take a pair of 120V-24V (or whatever) transformers which are larger than they need be (rule of thumb: if you need 20VA make these 30 or 40VA each) and hook them up back-to-back. i.e. your inverter output goes to the 120V side of the first transformer. Now the 24V side goes to the 24V side of the other, and the 120V side of the second transformer goes to your equipment. You've now just made an isolation transformer and, in addition to isolating the equipment from your electrical system (ground it yet!), you've also made a very handy (but inefficient as hell) 60Hz filter. Since the transformers are oversized you won't run into much trouble. Keep an eye on the temp (run the computer at full tilt for a number of hours to get the heat rise on the isolation transformer) and add a fan to them if needed.
To summarize: Squarewaves do affect equipment not designed for them.
Unless, of course, you've got some special application in mind that doesn't need much current, like keeping an ISDN line up during short blackouts or somesuch.
Actually telco equipment is designed to run off of -48VDC for precisely this reason. They can use the mains to float charge the batteries and if power goes, oh well. :-)
I've written a fairly detailled comment to both you and fwc here. Instead of copying and pasting it again, I've just made a link. Looking forward to comments.
Most inverters spit out a sinusoid-like CURRENT waveform because they have a large inductor or transformer to smooth out the current (inductors oppose fast current changes). The industry hasn't made linear-mode UPSes for at least a decade now, as the losses are too high.
Motors don't harm UPSes, UPSes harm motors. (more on this later.) A UPS is essentially a cheap VFD (Variable Frequency Drive). Unlike DC motors, you can't get full torque out of an AC motor by just reducing the voltage. The frequency and voltage must be kept in a specific ratio in order to keep the torque characteristics of the motor.
Unfortunately for UPSes, the voltage waveform they spit out is more or less a nasty-ass chopped up PWM waveform. Bad for anything, really. With motors (and most inductors) you will end up breaking down the insulation on the first few windings of the stator (in the case of a motor). That's why motor manufacturers (I'm talking 3-phase here) use "inverter-grade" wire; the insulation is better and can withstand this nasty voltage spiking.
And no, the more expensive UPSes still spit out a nasty-ass voltage wave form. You are paying for either a) a higher switching frequency, b) better PWM control (meaning a more balanced waveform), c) more stages (instead of just on-off, on, 1/2way and full) and/or c) heavy inductors or output transformers to smooth out the current waveform. I haven't seen a commercial step-like UPS in ages (too many components for not much advantage). Stick a scope probe across your high-end UPS; it's still got a nasty voltage waveform but chances are it's giving you a truer (closer to sine) current output than your $100 special.
Most PCs come with cheap-ass switchmode power supplies. There are MOVs in almost all equipment. Unfortunately most suppliers use 130V MOVs. The peak-to-peak voltage on standard North American outlets is about 170VAC (120VRMS is 170V p-p) -- those MOVs eventually fail because they're turning on at the peaks of each cycle for the briefest of moments. Sketch out a sinewave with 84V peaks; the amount of time you're over 60 degrees is only a few tens of degrees. Depending on the construction of the power supply you'll either blow the shit out of the MOV or the internal fuse eventually. I've fixed countless computer power supplies by replacing the MOV and/or fuse.
What's that got to do with inverters and UPSes? Simple, really: the PWM voltage output has lots of nice sharp edges and causes all kinds of ringing in any length of cable. It can help lead to premature failure of power supplies but when it does fail it looks no different than a normal equipment failure. Yeah there's a $25k replacement value given but that's only from lightning strike or power surge on the incoming side of the UPS. Read the fine print; it does not cover failures as I've described.
The only time that an AC motor will cause grief to a UPS is if you're powering it and your load is actually driving the motor; i.e. you're using a motor to power an uphill conveyor and the load on the conveyor gets to great as to start moving the belt downhill and drive the motor. This causes the motor to generate instead of.. uh.. "motorate" and raises the bus voltage on your poor UPS which was NOT designed to do so. This usually overvoltages the caps and as I've seen many times in our power lab, things come apart.