Certainly with some power cleanup on the front end, it could work, but it's not being shipped that way. The case-mod crowd is likely to think that if they just put a cigarette lighter plug on the thing, they'll have a car PC.
Well, as I said, they won't be far off. You will likely get away without any filtering on most modern vehicles... at least until something bad happens, and at $50 it'd be interesting to see just what it can take.
Are you sure about that? The efficiency graphs in the PDF show its ratings to at least 22VDC. Now granted it wouldn't operate correctly at 6V while starting but I don't think that's much of a problem. A nice pi filter on the front end of this, a transzorb and a nice 50V cap should make this work very well in automotive environments.
Afaik, electronics wouldn't - they'd just run faster in the cold.
Incorrect. I am a field applications engineer for an industrial power electronics manufacturer (no I'm not going to try and create an acronym for that).
Electronic devices tend to take more power to do the work designed to do. Thyristors in particular are harder to "fire" in extreme cold, requiring much heavier driver circuitry and higher current. The cold is welcome, though -- a lower ambient means that heatsinks work better and that you can get away with smaller devices to carry the same amount of current so long as your ambient stays cold. Also the entire field of superconductivity revolves around cooler temperatures, so the actual transfer of electrical power could be a lot more efficient on a cold planet.:-)
Re:I've tried the switch...
on
Why KDE Rules
·
· Score: 1
Ok, now here's the bad part: I decided that I do indeed like KDE and would like to continue using it, however it's too damn slow for my system! I even turned off a lot of features that are CPU intensive, but simply dragging a window around the desktop is spotty. My machine isn't too bad; it's 1130MHz and 512MB, Geforece2. Running Gnome on this machine is really snappy.
You must have something really misconfigured. I have a pretty much identical system (1GHz, 512M, shitty video card) and KDE 3.5 works very very well for what it's running on. On my other machine (3GHz, 1G, ATI 9550) it just screams.
One possiblity is that electronics/audio people often do have to work in situations where they wear a headphone with just a left-ear input (this is in situations like a TV station or film crew where the audio person needs to communicate with other people on set). Because of that left-ear only design, the workers might have slightly worse hearing in the left then in the right and compensate for it during recording. It's a stretch, but it might be a possiblity.
Nice theory, but if you think that music is mixed only "by ear" and nobody's watching a set of VU meters and other instrumentation to make sure the sound stage is set correctly then I'm fairly certain that you've never done this yourself.:-) At least any in any recording setup I've ever seen there is a lot of initial setup by ear but then things are all run through and verified with instrumentation.
It's also that hard drives have a high overhead cost. No matter what size the hard drive, you need some controlling stuff, a motor to drive the head, the head itself, and a hermetically sealed container.
The rest of your post is great, but hard drive cases are not hermetically sealed. They are pretty dust-tight but air (and moisture) passes through them just fine.
Sure, but we're talking 200M on a 2.5GB file. that's 8%. Frankly, if an 8% difference in speed is going to change your download time to your friend on IM by forty minutes, it's time to upgrade your connection.
It's been like this since the days of KDE 3.0, and each time a new version of KDE comes out, I check to see if they've fixed it. As of the most recent version, no dice. I'm currently stuck with Thunderbird until they fix it.
I've been using KDE since 3.0 and while I have had various problems over the years I've never run across this particular problem before. My IMAP server is Courier-IMAP... not sure if that makes any difference.
Also, have you posted a bug to bugs.kde.org about this? I imagine a bug like that would have been found and squashed very quickly.
I have a question -- I thought that the reason these pandemics tended to take out the healthy ones (as opposed to only killing off the immune suppressed/weak) was that they somehow got the body's immune system so frenzied up that it was out of control -- kind of like the opposite of what AIDS does... Is that incorrect? I also thought that Tamiflu was a type of immune suppressant which slowed down the immune system so that it was functioning "properly" and not too overzealous, and that's why it worked against H5N1.
I have the 650 and experience random reboots, usually when I'm trying to enter a note and oddly enough the last two times were both when I hit the 'j' button. The 650 is a really nice device though... Rip out the idiotic camera and give it a DECENT phone application and it'd be killer. (Honestly, why the fuck is the phone app so... weak? Not just unintuitive, but counter-intuitive operation, no voice call feature for BT... ugh.) I've been looking for a third-party phone app (and SIP phone app too) but so far no go.:-(
1519862 here... heh. I actually spoke with Ari and Sefi (I think that's what their names were) -- the original authors of ICQ several times about various things to make it better... Man that was a long time ago!
You're a little off on your AC motor efficiencies. I don't think there's a motor manufactured today that is under 96% efficient when running at load and at speed. Throw a VFD in front of it and yeah now you're making it less efficient, but that 80% efficiency figure is for older motors. It is in fact the high efficiencies that make across-the-line starting so damn nasty (8-12x FLA for the first half cycle, and typically 6-7x FLA for locked-rotor conditions, depending on the NEMA design class).
For our Linux boxes, we just run the following bash script every hour in cron:
Why in the hell do you do that? Go look up mdadm's --monitor --scan and -ft modes, and then configure smartd to also email you out warnings. Beats the shit out of some manual process that relies on the/proc format not changing over time!
Run an ethernet cable (yours perhaps) next to a space heater/box fan/large electric motor of your choice. Periodicaly turn that motor on and off. Instant link loss due to a spike on the line. WARNING, this one could jack up your switch/computer so be sensible.
You need a really poor equipment for that to be effective. Ethernet signals are differentially signalled, and the PHY should be subtracting the common mode noise to improve reliability. I deal with big electric motors all the time (50-500HP) and they can cause some really nasty dips/spikes on your power and induce all kinds of noise, especially if connected to a VFD. But have I ever had link loss due to this? Never. Shitty performance at times (again only with a VFD, ATL starting shouldn't ever cause any kind of noticeable network loss beyond a retransmit) but never link loss.
I will tell you one case. In BILLING! As a business rule we have to have a record of exactly what was billed and this can be handled in one of two ways or both. The first way is to write a record that has everything you could possibly need to bill (LOTS OF FIELDS). Lots of redundent data, yes, but the data is easy to get to when needed.
What's wrong with something like Order Number, Quantity, Part Number, Description, Price, Discount? That's 6 columns, 2 which would be copies from your global part list (Price and Description) but the copies are absolutely necessary since price and descriptions may change as the master list's updated. Your order table becomes huge in terms of rows, but that's not bad, and that's what things like views can help with. All your data's there, you have another order info table wiht order number, customer info, etc. and another table with shipping info, and another with billing info...
Your post sounds like you're doing this for a living, so I am certain I'm missing something crucial here. I have, however, done this too for a large manufacturing company. Please help enlighten me as to why a billing table would have hundreds of columns.
<a**hole> Right, then you're just at the whim of bulletin boards, lack of documentation, lack of drivers, lack of vendor support... </a**hole>
Oh I dunno, I far prefer that to "Nah, we're simply not going to solve that problem." At least I can do something about my own ignorance if the problem is big enough, and failing that I can pay someone to fix it for me. You simply can't do that (or at least the bar is significantly higher) with proprietary software.
One thing that drives me absolutely bat-shit crazy is having a problem and not being able to fix it. With Windows it's something you run against all the time. With Linux you still run against these things but there is simply such a vast variety of resources to draw on that the chances of hitting something that can't be solved is very small compared to with Windows. Yes, there's misinformation (honest and intentional) to wade through but at least you have the option to do so. That is worth a lot to me, and it's one of my biggest reasons for using Linux and OSS software in general.
Oh I dunno... I've got large hands (I can easily palm a standard-size basketball) and I have no problem on laptop keyboards at all. The big hands, however, do make it difficult to find cheap work gloves, play regular electric guitars and reach in behind little areas to grab screws that fell off the table and found the smallest place to settle.:-)
I think it's the 4 or 5 versions of my.cnf and the subsequent trying to run safe_mysqld and getting nothing when it crashes due to some lockfile missing or something that put me off. Postgres works out of the box without screwing around with the config file, and when it crashes, it tells you what the problem was very clearly. Sure, it may be suboptimal out of the box, but it worked, and then you could go find out why it wasn't screaming fast, which was usually because it was playing it safe and executing sync() after every transaction.
Sorry to tell you this, but your LEDs won't turn on, ever. And you're using more power than you need anyway. The only transistor necessary in that entire design is the one driving the speaker, which may not work anyway due to inductive and/or high current.
Email is not meant to be instant and unless its part of your job you should not let it dictate how you work.
Amen, brother.
I actuall turned off all notification of new email messages, but leave it open. Oh sweet bliss! When I started here ten years ago I also turned off the MDN/MRN of my email client, which pissed off some of the higher ups until I explained that if it's important or time-sensitive, it shouldn't be sent in an email. Pick up the phone or walk over to my desk, because there is no guarantee I read it or had time to respond to it when I did read it.
I still think my personal favourite time waster is someone sending me a fax, then emailing me to say the sent it, then coming by my desk to ask me if I'd read it yet.:-)
Slashdot Mirror
Certainly with some power cleanup on the front end, it could work, but it's not being shipped that way. The case-mod crowd is likely to think that if they just put a cigarette lighter plug on the thing, they'll have a car PC.
Well, as I said, they won't be far off. You will likely get away without any filtering on most modern vehicles... at least until something bad happens, and at $50 it'd be interesting to see just what it can take.
Are you sure about that? The efficiency graphs in the PDF show its ratings to at least 22VDC. Now granted it wouldn't operate correctly at 6V while starting but I don't think that's much of a problem. A nice pi filter on the front end of this, a transzorb and a nice 50V cap should make this work very well in automotive environments.
Afaik, electronics wouldn't - they'd just run faster in the cold.
Incorrect. I am a field applications engineer for an industrial power electronics manufacturer (no I'm not going to try and create an acronym for that).
Electronic devices tend to take more power to do the work designed to do. Thyristors in particular are harder to "fire" in extreme cold, requiring much heavier driver circuitry and higher current. The cold is welcome, though -- a lower ambient means that heatsinks work better and that you can get away with smaller devices to carry the same amount of current so long as your ambient stays cold. Also the entire field of superconductivity revolves around cooler temperatures, so the actual transfer of electrical power could be a lot more efficient on a cold planet. :-)
Ok, now here's the bad part: I decided that I do indeed like KDE and would like to continue using it, however it's too damn slow for my system! I even turned off a lot of features that are CPU intensive, but simply dragging a window around the desktop is spotty. My machine isn't too bad; it's 1130MHz and 512MB, Geforece2. Running Gnome on this machine is really snappy.
You must have something really misconfigured. I have a pretty much identical system (1GHz, 512M, shitty video card) and KDE 3.5 works very very well for what it's running on. On my other machine (3GHz, 1G, ATI 9550) it just screams.
One possiblity is that electronics/audio people often do have to work in situations where they wear a headphone with just a left-ear input (this is in situations like a TV station or film crew where the audio person needs to communicate with other people on set). Because of that left-ear only design, the workers might have slightly worse hearing in the left then in the right and compensate for it during recording. It's a stretch, but it might be a possiblity.
Nice theory, but if you think that music is mixed only "by ear" and nobody's watching a set of VU meters and other instrumentation to make sure the sound stage is set correctly then I'm fairly certain that you've never done this yourself. :-) At least any in any recording setup I've ever seen there is a lot of initial setup by ear but then things are all run through and verified with instrumentation.
It's also that hard drives have a high overhead cost. No matter what size the hard drive, you need some controlling stuff, a motor to drive the head, the head itself, and a hermetically sealed container.
The rest of your post is great, but hard drive cases are not hermetically sealed. They are pretty dust-tight but air (and moisture) passes through them just fine.
Hahahaha Yes i remember OWS. I wonder how many people actually lost data to it...
Sure, but we're talking 200M on a 2.5GB file. that's 8%. Frankly, if an 8% difference in speed is going to change your download time to your friend on IM by forty minutes, it's time to upgrade your connection.
It's been like this since the days of KDE 3.0, and each time a new version of KDE comes out, I check to see if they've fixed it. As of the most recent version, no dice. I'm currently stuck with Thunderbird until they fix it.
I've been using KDE since 3.0 and while I have had various problems over the years I've never run across this particular problem before. My IMAP server is Courier-IMAP... not sure if that makes any difference.
Also, have you posted a bug to bugs.kde.org about this? I imagine a bug like that would have been found and squashed very quickly.
Excellent post!
I have a question -- I thought that the reason these pandemics tended to take out the healthy ones (as opposed to only killing off the immune suppressed/weak) was that they somehow got the body's immune system so frenzied up that it was out of control -- kind of like the opposite of what AIDS does... Is that incorrect? I also thought that Tamiflu was a type of immune suppressant which slowed down the immune system so that it was functioning "properly" and not too overzealous, and that's why it worked against H5N1.
Amen.
I have the 650 and experience random reboots, usually when I'm trying to enter a note and oddly enough the last two times were both when I hit the 'j' button. The 650 is a really nice device though... Rip out the idiotic camera and give it a DECENT phone application and it'd be killer. (Honestly, why the fuck is the phone app so ... weak? Not just unintuitive, but counter-intuitive operation, no voice call feature for BT... ugh.) I've been looking for a third-party phone app (and SIP phone app too) but so far no go. :-(
1519862 here... heh. I actually spoke with Ari and Sefi (I think that's what their names were) -- the original authors of ICQ several times about various things to make it better... Man that was a long time ago!
You're a little off on your AC motor efficiencies. I don't think there's a motor manufactured today that is under 96% efficient when running at load and at speed. Throw a VFD in front of it and yeah now you're making it less efficient, but that 80% efficiency figure is for older motors. It is in fact the high efficiencies that make across-the-line starting so damn nasty (8-12x FLA for the first half cycle, and typically 6-7x FLA for locked-rotor conditions, depending on the NEMA design class).
For our Linux boxes, we just run the following bash script every hour in cron:
Why in the hell do you do that? Go look up mdadm's --monitor --scan and -ft modes, and then configure smartd to also email you out warnings. Beats the shit out of some manual process that relies on the /proc format not changing over time!
Run an ethernet cable (yours perhaps) next to a space heater/box fan/large electric motor of your choice. Periodicaly turn that motor on and off. Instant link loss due to a spike on the line. WARNING, this one could jack up your switch/computer so be sensible.
You need a really poor equipment for that to be effective. Ethernet signals are differentially signalled, and the PHY should be subtracting the common mode noise to improve reliability. I deal with big electric motors all the time (50-500HP) and they can cause some really nasty dips/spikes on your power and induce all kinds of noise, especially if connected to a VFD. But have I ever had link loss due to this? Never. Shitty performance at times (again only with a VFD, ATL starting shouldn't ever cause any kind of noticeable network loss beyond a retransmit) but never link loss.
Well, for starters, nobody in their right mind uses SELECT * for any kind of production environment. :-)
I will tell you one case. In BILLING! As a business rule we have to have a record of exactly what was billed and this can be handled in one of two ways or both. The first way is to write a record that has everything you could possibly need to bill (LOTS OF FIELDS). Lots of redundent data, yes, but the data is easy to get to when needed.
What's wrong with something like Order Number, Quantity, Part Number, Description, Price, Discount? That's 6 columns, 2 which would be copies from your global part list (Price and Description) but the copies are absolutely necessary since price and descriptions may change as the master list's updated. Your order table becomes huge in terms of rows, but that's not bad, and that's what things like views can help with. All your data's there, you have another order info table wiht order number, customer info, etc. and another table with shipping info, and another with billing info...
Your post sounds like you're doing this for a living, so I am certain I'm missing something crucial here. I have, however, done this too for a large manufacturing company. Please help enlighten me as to why a billing table would have hundreds of columns.
<a**hole> Right, then you're just at the whim of bulletin boards, lack of documentation, lack of drivers, lack of vendor support... </a**hole>
Oh I dunno, I far prefer that to "Nah, we're simply not going to solve that problem." At least I can do something about my own ignorance if the problem is big enough, and failing that I can pay someone to fix it for me. You simply can't do that (or at least the bar is significantly higher) with proprietary software.
One thing that drives me absolutely bat-shit crazy is having a problem and not being able to fix it. With Windows it's something you run against all the time. With Linux you still run against these things but there is simply such a vast variety of resources to draw on that the chances of hitting something that can't be solved is very small compared to with Windows. Yes, there's misinformation (honest and intentional) to wade through but at least you have the option to do so. That is worth a lot to me, and it's one of my biggest reasons for using Linux and OSS software in general.
Anyway, I'd always hate how I'd hit ctrl+d and it would tell me to type "exit" to logout.
Obviously you weren't tenatious enough to hit it 10 times and have it give up telling you how to do it and just log you out. :-)
Oh I dunno... I've got large hands (I can easily palm a standard-size basketball) and I have no problem on laptop keyboards at all. The big hands, however, do make it difficult to find cheap work gloves, play regular electric guitars and reach in behind little areas to grab screws that fell off the table and found the smallest place to settle. :-)
I think it's the 4 or 5 versions of my.cnf and the subsequent trying to run safe_mysqld and getting nothing when it crashes due to some lockfile missing or something that put me off. Postgres works out of the box without screwing around with the config file, and when it crashes, it tells you what the problem was very clearly. Sure, it may be suboptimal out of the box, but it worked, and then you could go find out why it wasn't screaming fast, which was usually because it was playing it safe and executing sync() after every transaction.
Not with the LED cathodes connected to +5, it isn't.
Sorry to tell you this, but your LEDs won't turn on, ever. And you're using more power than you need anyway. The only transistor necessary in that entire design is the one driving the speaker, which may not work anyway due to inductive and/or high current.
It's funny you should mention that. I have always had FAR more trouble installing mysql than postgres. Always.
Email is not meant to be instant and unless its part of your job you should not let it dictate how you work.
Amen, brother.
I actuall turned off all notification of new email messages, but leave it open. Oh sweet bliss! When I started here ten years ago I also turned off the MDN/MRN of my email client, which pissed off some of the higher ups until I explained that if it's important or time-sensitive, it shouldn't be sent in an email. Pick up the phone or walk over to my desk, because there is no guarantee I read it or had time to respond to it when I did read it.
I still think my personal favourite time waster is someone sending me a fax, then emailing me to say the sent it, then coming by my desk to ask me if I'd read it yet. :-)