Re: Long uptimes.
On Tue, Nov 17, 2009 at 11:52 PM, Ryan Simpkins wrote: > a NetWare server, or that a windows box ran for 2 weeks without a reboot. How > many times did you have to hit "remind me later" on the reboot dialog box? Ah, you haven't learned the secret-to-multi-week-Windows-uptimes. When the reboot dialog box pops up, don't click an option, just drag it out of your way. No more pop-ups, and your zombi^h^h^h^h^hmachine can run for days longer. -Derek /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
On Tue, Nov 17, 2009 at 5:37 PM, Ryan Simpkins wrote: > Found two gems: > > 16:00:59 up 1621 days, 9:22, 1 user, load average: 0.48, 0.46, 0.45 > 16:27:24 up 1618 days, 8:15, 1 user, load average: 0.75, 0.65, 0.57 > Found this on a switch I was working on the other day: The system uptime is 1628 days 22 hours 41 minutes 51 seconds The system started at 09:03:36 Mountain Fri Jun 03 2005 Set it and forget it, indeed. Josh /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
I know of several companies using Postgresql. I used both. I prefer Postgresql, but often end up programming in mysql just because there's an existing app built on mysql. On Tue, Nov 17, 2009 at 6:33 PM, Jim Wright wrote: > Are there many companies in Utah using Postgres? I have been trying to > do a search for companies doing work with it on a large scale and have > only found a handful. Backcountry and EMC and a few others and that is > about it. Why aren't a lot of companies using it? > > > > > > > > Jim Wright > > > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
On 11/17/2009 08:20 PM, Aaron Toponce wrote: Derek Davis wrote: Ha, that's nothing. I once had a Windows machine up for 2 weeks _straight_. http://uptime.netcraft.com/up/today/top.avg.html wow. that is significant in that their either 1) only gather windows statistics (with a token irix and linux server) or 2) they only gather data from a datacenter that is predominantly windows or 3) Linux/unix sysadmins are generally smart enough to patch their systems; windows admins are not. And I still do not believe the actual data as a system uptime. I have worked sites that have both windows and unix running the same type of system, and the lowly 5 year old unix box did ten times the traffic of the windows *cluster*, and had twice the uptime as the *cluster*. My guess is that the windows servers listed at the above url are actually clusters, that allow upgrades, reboots and testing of one at a time offline. Not true uptime at all. smime.p7s Description: S/MIME Cryptographic Signature /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
Steven Alligood wrote: > My guess is that the windows servers listed at the above url are > actually clusters, that allow upgrades, reboots and testing of one at a > time offline. Not true uptime at all. This reminds me of an article I read recently about software maintenance: http://cacm.acm.org/magazines/2009/11/48444-you-dont-know-jack-about-software-maintenance/fulltext It still galls me to have to reboot my Mac every month or so because of critical software updates. Maybe HFS+ can't replace in-use files like a normal inode filesystem can. Certainly that's the excuse Windows uses. In both Apple and Microsoft's case, however, it's pure laziness on their part, plain and simple. If you can save a programmer 40 hours of work by making customers bear the cost in time and money thousands of times over instead, they do it. But even on linux, a kernel update requires a reboot. Often the kernel update is critical because of a local exploit that it fixes. Why do we have to reboot just to patch a kernel? Sure it sounds complicated to patch a running kernel, but if I recall there were systems in the 70s that could do this. There must be mechanisms that could be used to facilitate this in modern Linux kernels. But like the Microsoft programmers, Linux programmers (aren't we all) are inherently lazy and shift the costs in a similar way. Seems to me if we focused on software maintenance (which really means more than bug-fixing; think evolution), not only would uptimes be ridiculously long, but software in general would be more reliable. But that'd go against human nature. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
On Tue, 2009-11-17 at 21:45 -0700, Sasha Pachev wrote: > MySQL and Postrgres come from two different backgrounds. Postgres was > created as an academic product, while MySQL was created to solve a > real-life problem. Thus Posgres is more academically correct, while > MySQL will deviated from academic correctness to achieve better > performance and improve user experience. I suppose for a small > business academic correctness is not as important as actually getting > the job done. The features you call academic I call essential. For a short and painful part of my career, I provided support for proprietary software. While Monty was still claiming "real developers don't need transactions" I was using "academic" features like triggers and such to bend the proprietary software to my will. MySQL has its current market share largely because of superior spin, not because Postgres was too "academic". -- "XML is like violence: if it doesn't solve your problem, you aren't using enough of it." - Chris Maden /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
On Wed, 2009-11-18 at 09:46 -0700, Michael Torrie wrote: > Steven Alligood wrote: > But even on linux, a kernel update requires a reboot. Often the kernel > update is critical because of a local exploit that it fixes. Why do we > have to reboot just to patch a kernel? Sure it sounds complicated to > patch a running kernel, but if I recall there were systems in the 70s > that could do this. There must be mechanisms that could be used to > facilitate this in modern Linux kernels. I haven't used this personally, but I hear it works well and is supported at least by Ubuntu: http://en.wikipedia.org/wiki/Ksplice http://www.ksplice.com/ /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
Michael Torrie writes: *snip* > But even on linux, a kernel update requires a reboot. Often the kernel > update is critical because of a local exploit that it fixes. Why do we > have to reboot just to patch a kernel? Sure it sounds complicated to > patch a running kernel, but if I recall there were systems in the 70s > that could do this. There must be mechanisms that could be used to > facilitate this in modern Linux kernels. But like the Microsoft > programmers, Linux programmers (aren't we all) are inherently lazy and > shift the costs in a similar way. I'm pretty sure people have made experimental implementations of Linux kernel swapping without rebooting. But, like everyone else, the Linux maintainers did some sort of cost/benefit analysis and decided it wasn't worth the development time to integrate it into the system. So, bascially what you're saying is that anyone who chooses to implement a different set of features than you'd like is inherently lazy? I'm sorry the world hasn't arranged itself to suit your needs. :) > Seems to me if we focused on software maintenance (which really means > more than bug-fixing; think evolution), not only would uptimes be > ridiculously long, but software in general would be more reliable. But > that'd go against human nature. OK, considering we're all pretty much running some form of a unix or windows system, none of which have a kernel architecture newer than sometime in the 90s, and some of which go back to the 70s... wouldn't you say that their development is focused on software maintenance? Maybe they're just driven by some metric other than ridiculously long uptimes. It would make sense, since to do so would be... ridiculous. --Levi /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
On Wed, 2009-11-18 at 09:46 -0700, Michael Torrie wrote: > But even on linux, a kernel update requires a reboot. Often the kernel > update is critical because of a local exploit that it fixes. Why do we > have to reboot just to patch a kernel? Sure it sounds complicated to > patch a running kernel, but if I recall there were systems in the 70s > that could do this. There must be mechanisms that could be used to > facilitate this in modern Linux kernels. It is possible. Over the last decade, I've seen several approaches attempted, but none has really achieved widespread use. Perhaps because the idea is too scary? Perhaps because no one cares enough? At least in part, I know MS is sitting on some patents even they obviously aren't using them themselves. The most recent example is Ksplice, which might stand a chance if it can escape its single vendor status. http://www.ksplice.com/ http://www.ksplice.com/uptrack/ -- "XML is like violence: if it doesn't solve your problem, you aren't using enough of it." - Chris Maden /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
Brian Simons wrote: > I haven't used this personally, but I hear it works well and is > supported at least by Ubuntu: > > http://en.wikipedia.org/wiki/Ksplice > http://www.ksplice.com/ I forgot about this little project. Of course it has the fatal flaw that it takes a bit of work on the part of kernel developers and distro makers to create the patch such that it can be applied to a running kernel! /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
Levi Pearson wrote: > So, bascially what you're saying is that anyone who chooses to implement > a different set of features than you'd like is inherently lazy? I'm > sorry the world hasn't arranged itself to suit your needs. :) In fact I am, although I'm not referring to my personal computing needs. The total economic cost to the world economy caused by requiring reboots is probably many times that of the cost of fixing the problem right originally. But it's a matter of who bears the cost. > OK, considering we're all pretty much running some form of a unix or > windows system, none of which have a kernel architecture newer than > sometime in the 90s, and some of which go back to the 70s... wouldn't > you say that their development is focused on software maintenance? Well, read the article. He makes it pretty clear that at one time software maintenance was the focus, but not anymore. > Maybe they're just driven by some metric other than ridiculously long > uptimes. It would make sense, since to do so would be... ridiculous. Yes I was afraid I'd be misconstrued as saying that ridiculously long uptimes (as in the kind reported by netcraft) are the goal. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
On Wed, 2009-11-18 at 10:13 -0700, Michael Torrie wrote: > Levi Pearson wrote: > > So, bascially what you're saying is that anyone who chooses to implement > > a different set of features than you'd like is inherently lazy? I'm > > sorry the world hasn't arranged itself to suit your needs. :) > > In fact I am, although I'm not referring to my personal computing needs. > The total economic cost to the world economy caused by requiring > reboots is probably many times that of the cost of fixing the problem > right originally. But it's a matter of who bears the cost. http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt -- "XML is like violence: if it doesn't solve your problem, you aren't using enough of it." - Chris Maden /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
On Wed, Nov 18, 2009 at 10:15:45AM -0700, Stuart Jansen wrote: > > http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt Maybe it's just because I'm on BYU's network, but I'm getting this: amcn...@maggie:~% host www.folklore.org Host www.folklore.org not found: 3(NXDOMAIN) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
On Wed, 2009-11-18 at 10:23 -0700, Andrew McNabb wrote: > On Wed, Nov 18, 2009 at 10:15:45AM -0700, Stuart Jansen wrote: > > > > http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt > > Maybe it's just because I'm on BYU's network, but I'm getting this: > > amcn...@maggie:~% host www.folklore.org > Host www.folklore.org not found: 3(NXDOMAIN) Tragic. -- "XML is like violence: if it doesn't solve your problem, you aren't using enough of it." - Chris Maden /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
On Tue, Nov 17, 2009 at 10:17 PM, Barry Roberts wrote: > Postgres has for years been much closer to feature parity with Oracle (and > maybe other commercial databases). I've used MySQL a lot for web, and > especially read-heavy applications. But when I already have code that > relies on Oracle features like transactions, triggers, and pl/sql, pg works > where MySQL wouldn't. I use Postgres for the same reason. Oracle has always been pre-ordained as the king at the companies I've worked at. So I've always had to work with Oracle, and over time, I've become used to the feature set it provides. Postgres provides most of the same features and is dang near a drop-in replacement for Oracle. That fact simplifies things for me as a developer. I write my logic once, knowing that the underlying database (be it Postgres or Oracle) will work the same. With MySQL, you may have to re-implement some of your data access logic because certain DB features don't exist. That being said, I've worked plenty with MySQL and have nothing bad to say about it. The features that it does supply are solid, its blazing fast, and has excellent cross-platform tools. If you don't need triggers or stored procs, it's just dandy. -Bryan /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
Michael Torrie writes: > Levi Pearson wrote: >> So, bascially what you're saying is that anyone who chooses to implement >> a different set of features than you'd like is inherently lazy? I'm >> sorry the world hasn't arranged itself to suit your needs. :) > > In fact I am, although I'm not referring to my personal computing needs. > The total economic cost to the world economy caused by requiring > reboots is probably many times that of the cost of fixing the problem > right originally. But it's a matter of who bears the cost. The total economic cost to the world economy caused by requiring reboots may indeed be significant in total dollars, but I'm pretty sure it's lost in the noise in a complete economic analysis of costs. You'll have to show me some real numbers, not silly Steve Jobs style thought experiments, to make me believe otherwise. When it comes down to it, the people who bear the costs don't consider them great enough to demand that particular feature, or else they would pay up front to have it implemented. >> OK, considering we're all pretty much running some form of a unix or >> windows system, none of which have a kernel architecture newer than >> sometime in the 90s, and some of which go back to the 70s... wouldn't >> you say that their development is focused on software maintenance? > > Well, read the article. He makes it pretty clear that at one time > software maintenance was the focus, but not anymore. I read the article. He made it clear that at one time, people did software maintenance differently than they do now, in general. But his primary example is MULTICS, which existed in an entirely different computing 'ecosystem' than exists now. And he also listed several modern elegant solutions to maintenance. Clearly Linux, OS X, BSD, Windows kernel, etc. are being maintained. They are evolving to meet new needs, new hardware, etc. Just because they can't be upgraded seamlessly doesn't mean there's no focus on maintenance, it just means they haven't determined that preventing the need for reboots is a necessary goal for them. For desktop systems, rebooting is not a significant cost, no matter how much it irks you. For most servers, it's not a big deal either, and if a single node's downtime would be expensive, you should have a redundant backup anyway and then you don't have any real downtime if you stagger the reboots. The fact is, the software and hardware we have now have evolved pretty well to meet the actual needs of the people who pay for them. Are they optimal? No, they kind of suck in a lot of ways. But that's not because people are lazy, it's because they're not in it for elegance, they're in it to use these things to make money. >> Maybe they're just driven by some metric other than ridiculously long >> uptimes. It would make sense, since to do so would be... ridiculous. > > Yes I was afraid I'd be misconstrued as saying that ridiculously long > uptimes (as in the kind reported by netcraft) are the goal. The goal is apparently to meet your standards. That's fine, but you'll only be disappointed. --Levi /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
On Wed, Nov 18, 2009 at 9:53 AM, Stuart Jansen wrote: > MySQL has its current market share largely because of superior spin, not > because Postgres was too "academic". I'd say MySQL has its market share because curious people could double-click on "setup.exe" and have a database. PostgreSQL only recently added support for Windows. Back when MySQL was gaining all of its momentum, the vast majority of developers were still running Windows desktops. If you wanted to play with Postgres, you had to first install Linux (SCARY!!) before you could even try out the database. Thus more developers cozied up to MySQL, pushed said technology to companies/employers, and now we have cats and dogs living together... mass hysteria. -Bryan /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
RE: Postgres in Utah
The reason I ask is I am working at a company in Utah County. They are a Postgres shop and are outsourcing there DBA responsibility to a National Consulting Firm. They want to bring in back in house but are not sure if there are qualified Postgres DBA's here in Utah. So we have 3 options we are looking at. Keep the consulting firm doing the DBA work indefinitely, Find a Postgres DBA in Utah, or hire someone with good Oracle, or Mysql skills and keep the consulting firm for 6 months and get this person trained on Postgres. I am trying to get as much information as I can before a decision is made. Thanks everyone. Jim Wright -Original Message- From: plug-boun...@plug.org [mailto:plug-boun...@plug.org] On Behalf Of Lance Grover Sent: Tuesday, November 17, 2009 9:19 PM To: Provo Linux Users Group Subject: Re: Postgres in Utah I work for a software company that has 4 major projects that each use postgresql along with many minor projects that use it. Major projects are gigabytes in size. What exactly are you looking for? Are you just curious or do you have a purpose to asking? -Lance On 11/17/09, Jason Jones wrote: > Though it won't for long, I know Nature's Way currently uses it. > > --Jason > > On Tue, Nov 17, 2009 at 7:40 PM, Doran L. Barton wrote: > >> On Tuesday 17 November 2009 18:33:16 Jim Wright wrote: >> > Are there many companies in Utah using Postgres? I have been trying to >> > do a search for companies doing work with it on a large scale and have >> > only found a handful. Backcountry and EMC and a few others and that is >> > about it. Why aren't a lot of companies using it? >> >> I can't think of any offhand besides the ones you've mentioned. When I had >> my >> own business - Iodynamics - we did just about everything on top of >> PostgreSQL. >> I've always felt it to be a superior product to MySQL for a variety of >> reasons. >> >> -- >> Doran L. "Fozz" Barton >> Open-source developer, sysadmin, consultant, and all-around geeky dude >> "Cesar inspired his men by stating, 'I came, I saw, I left.'" >>-- Seen in a school report >> >> >> /* >> PLUG: http://plug.org, #utah on irc.freenode.net >> Unsubscribe: http://plug.org/mailman/options/plug >> Don't fear the penguin. >> */ >> > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > -- Sent from my mobile device Thanks, Lance Grover /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */ /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
Stuart Jansen wrote: > On Wed, 2009-11-18 at 10:23 -0700, Andrew McNabb wrote: >> On Wed, Nov 18, 2009 at 10:15:45AM -0700, Stuart Jansen wrote: >>> http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt >> Maybe it's just because I'm on BYU's network, but I'm getting this: >> >> amcn...@maggie:~% host www.folklore.org >> Host www.folklore.org not found: 3(NXDOMAIN) > > Tragic. I can't resolve folklore.org either. The problem is unrelated to BYU. Shane /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
On Nov 18, 2009, at 11:01 AM, Shane Hathaway wrote: > Stuart Jansen wrote: >> On Wed, 2009-11-18 at 10:23 -0700, Andrew McNabb wrote: >>> On Wed, Nov 18, 2009 at 10:15:45AM -0700, Stuart Jansen wrote: http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt >>> Maybe it's just because I'm on BYU's network, but I'm getting this: >>> >>> amcn...@maggie:~% host www.folklore.org >>> Host www.folklore.org not found: 3(NXDOMAIN) >> >> Tragic. > > I can't resolve folklore.org either. The problem is unrelated to BYU. > > Shane > I didn't have any problems getting to it. Dallin /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Long uptimes.
http://www.folklore.org/StoryView.py?project=Macintosh&story=Saving_Lives.txt Maybe it's just because I'm on BYU's network, but I'm getting this: amcn...@maggie:~% host www.folklore.org Host www.folklore.org not found: 3(NXDOMAIN) Tragic. I can't resolve folklore.org either. The problem is unrelated to BYU. Shane I didn't have any problems getting to it. Should work if they have a standard resolver (and aren't playing some games with their resolution). The delegation for the site is a little non-standard, but it does have one glue record and it does resolve from both nameservers listed on the root servers. smime.p7s Description: S/MIME Cryptographic Signature /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
Actually mysql has triggers. On Wed, Nov 18, 2009 at 10:50 AM, Bryan Sant wrote: > On Tue, Nov 17, 2009 at 10:17 PM, Barry Roberts wrote: > > Postgres has for years been much closer to feature parity with Oracle > (and > > maybe other commercial databases). I've used MySQL a lot for web, and > > especially read-heavy applications. But when I already have code that > > relies on Oracle features like transactions, triggers, and pl/sql, pg > works > > where MySQL wouldn't. > > I use Postgres for the same reason. Oracle has always been > pre-ordained as the king at the companies I've worked at. So I've > always had to work with Oracle, and over time, I've become used to the > feature set it provides. Postgres provides most of the same features > and is dang near a drop-in replacement for Oracle. That fact > simplifies things for me as a developer. I write my logic once, > knowing that the underlying database (be it Postgres or Oracle) will > work the same. With MySQL, you may have to re-implement some of your > data access logic because certain DB features don't exist. > > That being said, I've worked plenty with MySQL and have nothing bad to > say about it. The features that it does supply are solid, its blazing > fast, and has excellent cross-platform tools. If you don't need > triggers or stored procs, it's just dandy. > > -Bryan > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
On Wed, 2009-11-18 at 16:10 -0700, Merrill Oveson wrote: > Actually mysql has triggers. Has. Present tense. For a long time it didn't. For some of us it's hard to accept that MySQL is finally growing up and becoming a real database instead of a glorified filesystem. More importantly, data integrity is still easy to get wrong with MySQL. http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL_2009#Reliability -- "XML is like violence: if it doesn't solve your problem, you aren't using enough of it." - Chris Maden /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
On Wednesday 18 November 2009, Stuart Jansen wrote: > While > Monty was still claiming "real developers don't need transactions" I was > using "academic" features like triggers and such to bend the proprietary > software to my will. Stuart Jansen Victorious! -- Jacob Albretsen ja...@xmission.com /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
On Wednesday 18 November 2009 16:10:26 Merrill Oveson wrote: > Actually mysql has triggers. Yes, MySQL has a lot of these things... now. But for a long, long time, it did not. Before the InnoDB table type came around, most of these features were impossible. I think Sasha has nailed it in his description of the two RDBMSs: MySQL was hacked together with features on an as-needed basis. PostgreSQL was built from the ground up with fairly robust relational database requirements. Things like transactions, sub-selects, stored procedures, etc. have been part of the product for a long, long time, if not from inception. With this in mind, why are people drawn to MySQL over PostgreSQL? I've asked myself this question for years. I maintain and develop w/ both backends and I find PostgreSQL easier to administer. I guess the pg_hba.conf file can be a hurdle for some people. Is the lack of something like phpMyAdmin a deterrent? I've never used GUI or web-based tools to interact with either PostgreSQL or MySQL. -- Doran L. "Fozz" Barton Open-source developer, sysadmin, consultant, and all-around geeky dude "We are ecologically minded. This package will self-destruct in Mother Earth." -- Seen on a Japan package signature.asc Description: This is a digitally signed message part. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
Doran: > Is the lack of something like phpMyAdmin a deterrent? http://phppgadmin.sourceforge.net Jeff /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
On Wednesday 18 November 2009 18:06:43 Jeff Schroeder wrote: > Doran: > > Is the lack of something like phpMyAdmin a deterrent? > > http://phppgadmin.sourceforge.net Excellent. Thanks. This is one area PostgreSQL was lacking in before. -- Doran L. "Fozz" Barton Open-source developer, sysadmin, consultant, and all-around geeky dude "Used Cars: Why go elsewhere to be cheated. Come here first." -- Seen in newspaper ad signature.asc Description: This is a digitally signed message part. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
>The reason I ask is I am working at a company in Utah County. They are >a Postgres shop and are outsourcing there DBA responsibility to a >National Consulting Firm. They want to bring in back in house but are >not sure if there are qualified Postgres DBA's here in Utah. So we have >3 options we are looking at. Keep the consulting firm doing the DBA >work indefinitely, Find a Postgres DBA in Utah, or hire someone with >good Oracle, or Mysql skills and keep the consulting firm for 6 months >and get this person trained on Postgres. I am trying to get as much >information as I can before a decision is made. I'd say hire a sharp guy that knows how databases work regardless of his specific experience and do not worry if that knowledge came from Oracle, MySQL, Postgres, or any other product. To evaluate, have him solve a real-life issue that the customer is experiencing and watch what he does. Pay particular attention to how he fills in the gaps in his initial lack of experience. The guy you want will know what it is that he does not know and needs to learn, will issue correct Google queries, look at the correct manual pages, within those search exactly for the information he needs, and will quickly apply it to produce a solution. I believe in the long run the performance of a programmer/DBA is a function of his general aptitude in the area of computing rather than initial familiarity with a specific product. -- Sasha Pachev AskSasha Linux Consulting http://asksasha.com Fast Running Blog. http://fastrunningblog.com Run. Blog. Improve. Repeat. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
On Wed, November 18, 2009 6:15 pm, Doran L. Barton wrote: > On Wednesday 18 November 2009 18:06:43 Jeff Schroeder wrote: >> Doran: >> > Is the lack of something like phpMyAdmin a deterrent? >> >> http://phppgadmin.sourceforge.net > > Excellent. Thanks. This is one area PostgreSQL was lacking in before. Unless it's changed a LOT in the last year, it's still lacking. phppgadmin is nowhere /near/ the tool phpMyAdmin is. It's better than nothing... but it's still missing a LOT of the features that I find very useful in PMA. -- Matthew Walker Kydance Hosting & Consulting, Inc. - http://www.kydance.net/ PHP, Perl, and Web Development - Linux Server Administration /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Distance Sensors
Question for EE geeks. I want to have something like this. Sensor A, Sensor B, Sensor C, let's say up to 16 sensors. Each separated from each other by no more than 2 meters at any given time. Each sensor needs to be small enough that if you attached it to the body and tried to run you would not feel encumbered. So maybe up to the size of a watch. Powered by something like CR2032 battery. Then there is a base. The base can ask any of the sensors how far away they are from a given peer at any time. Base can be stationary and plug into a wall. Questions: - What is the technical term for something like this? - If something like this exists, can I get the precision of 0.1 cm and the ability to query 1000 distances per second for a reasonable cost (let's say under $1000)? - Assuming the answer to the previous questions is that it is technologically possible, but not for the given price. Suppose a demand arose for a system like this to where you had, let's say, a million potential customers. Would it be economically viable to manufacture a system like this for less than $1000 for a base + 16 sensors? If it is not obvious, and also to keep the discussion on topic, I do want to be able to use Linux to control the base and collect the data. I have initially thought of it as a tool to evaluate running form, but the applications are numerous. E.g. you could use it to detect improper sitting posture and sound an alarm until the person adjusted his position. -- Sasha Pachev AskSasha Linux Consulting http://asksasha.com Fast Running Blog. http://fastrunningblog.com Run. Blog. Improve. Repeat. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Postgres in Utah
On Wed, 2009-11-18 at 18:35 -0700, Sasha Pachev wrote: > I'd say hire a sharp guy that knows how databases work regardless of > his specific experience and do not worry if that knowledge came from > Oracle, MySQL, Postgres, or any other product. *snip* > I believe in the long run the performance of a programmer/DBA is a > function of his general aptitude in the area of computing rather than > initial familiarity with a specific product. Well, maybe worry about Oracle experience. The person has to be willing to learn something new, and Oracle is a safe choice, not a passionate choice. -- "XML is like violence: if it doesn't solve your problem, you aren't using enough of it." - Chris Maden /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
Re: Distance Sensors
Sasha Pachev writes: > Questions: > > - What is the technical term for something like this? This is generally called a motion capture system. It sounds like you specifically want a magnetic motion capture system. The base station projects a magnetic field, and each sensor has 3 coils that measure the magnetic flux at their position. They transmit this data back to the base station, which can then figure out the position and orientation of each sensor. > - If something like this exists, can I get the precision of 0.1 cm > and the ability to query 1000 distances per second for a reasonable > cost (let's say under $1000)? I haven't seen anything that supports that high of a sample rate and that fine of resolution, but I'm pretty sure you can get by with less. I'm not really sure what they cost; it probably depends on what kind of a deal you can work with the sales people. > - Assuming the answer to the previous questions is that it is > technologically possible, but not for the given price. Suppose a > demand arose for a system like this to where you had, let's say, a > million potential customers. Would it be economically viable to > manufacture a system like this for less than $1000 for a base + 16 > sensors? A million total potential customers is not exactly a huge number these days, but I don't really know what the motion capture market is like. You could contact these guys and see what they'd sell this system for: http://www.polhemus.com/?page=Motion_Liberty_Latus It doesn't look like it's cheap, though. > If it is not obvious, and also to keep the discussion on topic, I do > want to be able to use Linux to control the base and collect the data. Since when do we have to be on topic here? ;) --Levi /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
