Comment Re:We're the great fudgers (Score 1) 449
Both parties talk about change but the reality is that they keep the status quo once they get it
The status is not quo.
The world is a mess, and I just need to... rule it.
Both parties talk about change but the reality is that they keep the status quo once they get it
The status is not quo.
The world is a mess, and I just need to... rule it.
Yeah, but it changes them to DOS format when you save, with no option to keep the UNIX line endings
Good thing vim has a windows version.
While SQLite3 doesn't support true concurrency, it's generally good enough for things like MythTV. The locking is only slightly more clunky than MyISAM's.
-Does it silently accept CONSTRAINTS other than FOREIGN KEYs and then not use them?
Why is ignoring FOREIGN KEYs okay? A constraint is a constraint, IMO.
Last I checked FKs worked, if you're using InnoDB, and then only kinda (no deferred checking, which is the SQL standard default).
To be honest, and I'm a total pgsql fan, you usually wind up needing to edit pg_hba.conf and reload to allow external access. But yeah, it is about as easy to me as mysql.
Although, the primary deployment for MySQL seems to be running on the same machine as the web server. In a direct comparison of that case, you don't even need to change pg_hba.conf.
The default config isn't secure if you have untrusted users on the machine (i.e. hosting service), unless you used "initdb -A md5" or something similar, but it's easy to change.
My favorite auth method for server-in-a-box is "ident sameuser" over UNIX sockets. In that case it seamlessly integrates with the OS's underlying security model, so all I have to do is "CREATE USER webapp;", and the user 'webapp' can connect as itself (and only as itself) with no password.
I've used MySQL for years...
The same thing in MySQL would have taken me thirty seconds now, and no more than 15 minutes when I was starting out. With Postgres, it took me upwards of 20 minutes when it should have taken much less time.
That's because you know MySQL, so of course something that works differently is going to be more work for you to figure out.
I've used PostgreSQL for years, when I had to set up a MySQL database for some php app it took much more than 15 minutes to figure it out and get it running. The primary problem was MySQL's obtuse user management system.
With PostgreSQL I know that it's secure by default -- the default user has no password, so even if you enable password authentication it won't work (because it has no password!). You log in locally with trusted authentication, and issue the very logical CREATE USER. Edit the self-documented config file to allow remote hosts to access the database using your preferred authenticaion method, and you're done.
With MySQL, new users are automagically created by the GRANT command?! Huh? On top of that, passwords are apparently specific to a certain host string. Bizarre. Do I need to use localhost for the actual machine name for local users? What about remote machine without a reverse DNS entry? What's the order of precedence for '%' vs a more specific name?
Oh, the default 'root' account has no password
Time to check the startup guides. Well, one just has a single password change, another has 3 or 4 lines of 'delete from user...'. The reference for GRANT just has a bunch of caveats and warnings, and the "User Account Management" section goes on and on and somehow doesn't manage to tell me what I want to know.
To this day I'm not 100% sure if the MySQL install is secure. I decided my time would be better spent eliminating the MySQL-isms from the app in question so that it can run on Postgres like everything else on the server. There are some very strange queries in there - a lot of GROUP BY expressions that make no sense and aren't valid SQL. Some of it I'm not sure how it ever worked.
Bit-robbing is a bad example as it steals the LSB from every channel at a constant interval. It doesn't pick and choose which ones to reduce the bit-rate on.
That info is a little out of date, too. At least to the endpoint, PRI is the preferred method of attaching to the PSTN. You do give up one of the channels to be dedicated to signaling, but get vastly superior channel allocation.
I'm not sure what the telcos are using for the big trunks, but I'd imagine (hope) they have something a little more advanced than basic T1 by now.
"No job too big; no fee too big!" -- Dr. Peter Venkman, "Ghost-busters"