A key issue these days is to not repeat the Ross Perot election. Perot was a spoiler and resulted in a Democrat winning the office (and winning a second term with a huge margin compared to his first). I attended my Republican caucus this year, and such thinking was palpable: a Party win is much more important than voting for your idealogical match. Both parties learned this from spoiler-third-party elections like Clinton/Perot/Bush 1.
...events/races(lots of close cyclist make me nervous, and odds of an accident likely go up)
Exactly how I broke my collarbone and shattered my helmet a month ago. My convalescence has proved to me exactly how much daily bicycling was helping keep my weight under control!
Helmets save lives in a group setting, no doubt about it. After looking at my shattered helmet, I'm pretty certain my crash would have been a brains-on-pavement situation. As it was, I suffered from the concussion for several days.
@erroneus:
The extra 90 minutes spent on my bike commute daily burns -- depending on intensity -- up to 600 calories. I've repeatedly proven this to myself with pedantic calorie-counting, weighing, and measuring of my food along with long-term weight trend analysis. Doing this five days a week is 3,000 calories.
My longer rides on Sundays consistently burn between 1,600 to 4,000 calories. Proven in my eating and exercise logs, with predictable results in my physique, lean to fat ratio, and very repeatable once I got my particular burn-rates figured out. Add this to the previous bicycle commute, and I'm burning an extra 4,600 to 7,000 calories per week over someone sedentary who excels at changing "what they eat".
Exercise -- particularly bicycling, which often involves longer bouts of exercise at lower intensity -- has a measurable and profound effect on obesity on both an individual and statistical level. To claim a lack of activity has no impact on likelihood of obesity is a claim without merit.
"Eating Wrong" does cause obesity, but so does lack of exercise. The two together are the toxic mixture powering today's extraordinary obesity rates.
You can manage your body fat strictly through caloric restriction. But that's much, much harder than preventing obesity through a combined modest caloric restriction and exercise.
Figuring 'something' out from WiFi works only in dense urban environments, and even then isn't good enough for turn by turn navigation, which Apple claims is supported by the iPod Touch and iPad,
Close, but not quite. I live in a rural area, and my iPad figures out locations pretty reasonably within 300 feet or so. Admittedly it will struggle with location in the middle of nowhere, but a "dense urban environment" is not required. Somewhere within line-of-sight to a house or two that has a wifi router (almost all houses in USA these days) will do.
If you amend your statement to "urban or suburban environment", I agree with you!
Try ordering a barrel or bolt without a FFL (Federal Firearms License). You won't get very far. Now if you have your own CNC shop AND a 3-D plastic printer, well then you're on your way...
I don't think that statement is correct. I can order barrels, slides, magazines, ammunition, springs, rails, pins, and all kinds of miscellaneous parts without a FFL or a background check in the US. For instance, a common upgrade to a Kahr CM9 if someone wants greater precision is to purchase a replacement polygonally-rifled barrel made for the higher-end the PM9 . Of course, at that price point you may as well have purchased a PM9 in the first place.
I can buy everything except the receiver without a background check. I'm not sure what you're referring to above.
While I agree substantially with your premise, I disagree with your comparison of Amtrak vs. airlines. The airlines are subsidized to the tune of $3700 per empty seat on their commuter flights. This is a HUGE subsidy from the US government, and its impact on airline prices cannot be underestimated.
Quick summary:
http://pjmedia.com/blog/how-we-pay-3700-per-passenger-to-subsidize-airline-tickets/
Pick a different example and I think we're on the same page
That's covered in the article. 21" racks within the current 24" standard rack size. By eliminating cable mass in favor of bus-bars, you gain the two inches "free" in your rack footprint. If the rack's designed right, you could even keep the same seismic bracing.
It's been said that the whole reason Oracle bought Sun was to clobber Google with the Java patents so they could cross-license the map/reduce patents and get back to an Oracle database that could scale.
Sure it's been said. By those who don't know what they're talking about.
Patent licensing -- in my opinion -- would be somewhere very near the bottom of any reason for acquiring Sun. It was, plainly put, a great deal at a great time, and some huge innovations have already come out of it. Just a few:
* Exadata V2. Many times the power for Oracle Database for much reduced power, space, cooling, and price compared to the V1 offering with HP. I'm seriously blown away by how much performance these things can put out... and we have hundreds side-by-side here in the data center where I work. Sun hardware made the difference, and it's gotta be seen to be believed.
* Sun/Oracle 7000-series NAS appliances. I'll be the first to admit they got off to a rocky start, but since the 2010Q3.4 release they've been solid and high-performing in mirrored and triple-mirrored configurations. ZFS on RAIDZ/RAIDZ2 definitely needs some work to improve IOPS for OLTP loads, but mirrored configs really cook under anything but the most extreme high-data, low-IOPS loads we can throw at it.
* Oracle Secure Backup on Sparc. We had to go this route to get the I/O performance we need to back up the world's largest Oracle databases. Nothing else had what it took; x86 just couldn't keep up with the I/O to dozens of T10000 T2 tapes simultaneously.
Sun hardware is making this and many other things possible. End-to-end custom-tailoring our apps onto custom-built hardware has enabled performance gains we only dreamed of five years ago.
Disclaimer: Yes, I work for Oracle. By choice, not necessity.
Postgres combined with commodity hardware and database joining extensions like dblink allow you to partition data across dozens (or hundreds) of commodity servers, allowing you to provide massively parallel access to massively large datasets without compromising performance. The cost is developer competence.
You nailed it. Postgres is a superb product, and a stellar example of open-source done right. Incredibly flexible, incredibly tough, easy to use for a newbie yet powerful enough for an expert, and an all-around winner. But if someone is going to shoot themselves in the foot, Postgres (and MySQL) gives them the gun & bullets.
The difference between Postgres and Oracle seems to be on focus: Oracle seems to seek limits to the damage caused by idiot developers, while Postgres (seems to) seek to maximize the capabilities of competent developers. It's an exercise to you to decide which approach is more productive in the long haul.
If I hadn't already participated in this discussion and therefore couldn't moderate, I'd totally mod you up for that. Very insightful comment.
However, I don't necessarily agree with you implication that Oracle mainly seeks to minimize damage over maximizing performance or capability, nor do I agree that the focus of the databases are the primary differences. Your comment above is simply one of those statements that really *feels* true, even if you couldn't point out the truth on a comparison spec sheet
Disclaimer: I work for Oracle; my opinions are my own, and not those of my employer.
In what world do you live? Oracle DB is the only great product they have, the rest is complete and utter crap, and they don't even know how to maintain them.
Disclaimer: I work at Oracle. Your description does not match my experience.
We've been trying for months now to get someone from Oracle to explain us why our OSB does not work as it should, and even the guy from engineering that they shipped over half the world was just as clueless as we are.
I and my team use OSB every day (about 80/20 to Netbackup) to back up petabytes of data. The chances are very good you've encountered one of numerous hardware-related gotchas that can derail success with OSB. I like the product, but the hardware support can be a killer.
Let me know the My Oracle Support number you filed and I'll take a look and see if I or my team might be able to chime in if we've seen the problem before.
Siebel has been going downhill ever since they purchased it.
I was part of the Siebel acquisition.
In fairness, Siebel struggled because within a few months of acquisition, developers had to change focus. Previously it was almost-exclusively a Windows/Internet Explorer product, heavily tailored to that environment, including Windows on the back-end most often with AIX running DB2 for the database. The slowdown in Siebel development -- in my opinion -- was largely due to the huge Linux porting & HTML standardization effort.
Today's Siebel runs on Linux middle-tiers with Oracle database under the hood. And its stability is better for it. Every time you use My Oracle Support, you're actually using Siebel.
Additionally, you're seeing the results of that effort reflected in CRM Fusion. Of course the product has bugs, but we're eating our own dogfood every day and we're acutely aware of most of them!
Fusion is still just a dream that doesn't really work, the list goes on...
Wow, I must dream like every day. I support the boxes it runs on, I use the product, and so do tens of thousands of others. It's ambitious, and it was a huge effort, but I fully expect it to mop the floor with other products. We're using portions of it throughout many of our other enterprise products right now.
And you know what, it's because all the good engineers don't want to work at Oracle.
Really? I work with world-class teams every day that amaze me with innovations large and small. There are pockets of unhappiness, for sure, and now that the tech market is improving there are occasional defections. I've been here almost eight years now, and it's not for lack of options. I interview at least four times a year for other positions elsewhere. I choose to remain.
Why? Great environment. Great commute. Incredibly intelligent co-workers. Highly-focused training in an area I love (storage & backup). Market pay. Lots more.
And they are trying hard to hide that they have people leaving the company in droves, leaving people with very little experience maintaining software that they have no clue about.
Depends on the team. I'm friends with people all over in tech, and right now the market is driving everyone job-hopping. Oracle is HUGE, so from what I can see it's just affecting us as much as anyone else... but with tens of thousands of employees, everybody knows somebody who's left recently.
There were mass defections shortly before & after the Sun acquisition. I've been through numerous acquisitions with several companies, and it apparently comes with the territory. I don't see any more "droves" of people leaving than before. But Oracle's working a little harder to keep the good ones now that the tech job market has improved so much.
To sum up... it's unfortunate you've had a bad experience with support on a few products. Rapid changes in our product offerings definitely have an effect on our support models. But give me the MOS SR # you filed against your OSB problem and if my team has seen it before I'll chime in.
Feel free to email me. And remember all opinions I expressed here are my own, not those of my employer.
The E-Ink versions of the Kindle do what they are supposed to do very, very well. If I sit down to read a book on an E-Ink screen, I can read for several hours without eyestrain. The Kindle E-Ink UI is sluggish, but it is generally consistently sluggish, and my brain soon ignores the sluggishness. The slow page-turning stops mattering after a while -- it takes some time to flip a page on a physical book, too! -- and the lack of glare, easy-read screen, and ability to read in sunlight combine to create a pleasant reading experience.
I cannot sit and read for hours on my iPad. After a two or three-hour reading session on the iPad -- even with regular breaks! -- the world around me is fuzzy and I'm often nursing the beginnings of a headache. The Barnes & Noble Nook Color shared the same problem. I don't expect any different from the Fire. Close-range LCD creates eyestrain in many people, despite manufacturer claims to the contrary. I can't read an LCD comfortably outdoors in the sunlight, and the glare is horrendous in many situations.
The Kindle Fire, for me, would only be interesting to me as a replacement for my iPad. So what would I get for $200? A device that isn't a great book reader because I can't read for longer than an hour on it without eyestrain. And now reports claim it shares the same problem every Android device I've used so far suffers from as well: inconsistently sluggish performance. That's the very reason I own an iPad 2 instead of one of the many excellent, high-spec Android tablets out there. UI sluggishness bugs the heck out of me most when it's inconsistent, and I suspect I'm not alone in that observation. The human brain is an organ of prediction, and performance must be predictable to take advantage of that fact.
The Kindle Fire? Meh, I'll pass, while once again pondering the thought of selling my iPad 2. That is, until the next time I play Dungeon Defenders, want to surf quickly without firing up the laptop, or watch a movie when the kids are using the big screen. The Kindle Fire might survive in that ecosystem and might not. I see no compelling reason to pick one up.
Snapshots are read-only. Budget a little excess capacity to hold snapshot churn and an off-site replication setup using a filesystem that supports snapshots. It's an unconventional backup, but satisfactory for many uses.
Taking one way snapshots over a network link to a remote location, for instance using rsync and a remote filesystem that supports snapshots, can be a viable solution for short term backups, but if you want longer term retention, "old hat" backup equipment still is a viable solution.
I agree, for varying values of "short term". "Short term" can mean *years* for low-variability filesystems.
If you plan to drop data somewhere and not change it very often after that, snapshots offer a great long-term storage option as long as you have some sort of off-site replication taking place.
That said, I administer a gigantic SL8500 tape library for exactly those cases where disks won't do.
Be aware that most of the time, snapshots are not whole copies of the volume they've snapshotted, merely a diff to the live version - one must copy the snapshot through some other method before a full copy exists (although it is conceivable that the snapshot mechanism will handle this automatically).
Not quite. Imagine a snapshot this way. You have a file "A". It takes up blocks 1, 2, and 3 on your filesystem. You then snapshot the filesystem containing "A" with the name "first". You lose about 32kbytes (or so, depends on your structure) of data space to store the block layout.
Then you lengthen file "A" into revision "B". "B" is twice as big, but the first half of the file is unchanged. It now occupies blocks 1, 2, 3, 4, 5, and 6. You snapshot again with the name "second".
Then you alter file "B" into revision "C". This version also takes six blocks, but the changes are in blocks 2 and 3. A snapshotting filesystem cannot change those existing blocks! It has to allocate new blocks because the old blocks are marked as parts of snapshot "first" and "second". So your file now occupies blocks 1, 7, 8, 4, 5, and 6. You snapshot again with the name "third".
Then you don't need the file anymore and delete it. Then you take a snapshot of the filesystem called "fourth".
The full copy of the file exists. If you delete snapshot "first", blocks 1, 2, and 3 are still not available for overwrite because snapshot "second" also owns them.
So basically, you got snapshots backward
If this explanation is confusing, feel free to email me directly: matthew@barnson.org. I'm glad to clear up misconceptions about what a snapshot is or is not, because it's a far more robust and reliable system than you suggested!
Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?
