From what I remember NT had some sort of time overflow that would happen after something like a month that caused all sorts of instability.
And from what I remember it was SOP to reboot at least once a week. Daily wasn't uncommon either.
420 karma · joined February 27, 2009
And from what I remember it was SOP to reboot at least once a week. Daily wasn't uncommon either.
For 1), you would have to upload the ssl cert and key into the third party's service. They would then have to configure their web server to use the correct ssl cert for your CNAME. On top of that they would need to add support for whatever intermediate and CA certs that have to be included. Some CAs require multiple intermediate certs. If you simply upload the main cert and key then older browsers, android, and IE will all freak out. I have missed an intermediate cert before and it's not fun to track down the root cause. There are no errors in apache; you just get reports of your site being compromised or the cert expired.
Not to mention the problem of SSL accelerators/load balances and costs associated with adding new SSL certs and keys to them.
Even if they figured out a way to automate the cert/key/PEM/intermediate upload and server config steps then the one IP per ssl cert problem kicks in. Basically, the SSL handshake goes something like this: 1) browser looks up IP address for host. 2) browser connects to IP and establishes a ssl connection. 3) server reads the request and serves up content based on hostname. The problem is that the server does not get the hostname during step 2 so it can only serve up one cert for the IP.
Now, there is a process called SNI that attempts to solve it. Unfortunately it's not well supported enough to use. Mostly because it does not work on IE on XP at all (regardless of version).
And that's why third parties generally don't offer SSL CNAMEs.
Once you get into 45° and 60° banks the forces are disorienting and it's far easier to look out the window at the ground and the real horizon.
Training or not, it's far easier to look out the window to make turns. You can see if the horizon is starting to move. If you sit there and watch the compass you can easily enter a stall or a dive without realizing it. Especially since your turns are not going to be coordinated (you won't be using the rudder effectively so the forces on your head will not be what you're used to).
It also appears to be abandonware.
PgAdmin III is currently the best (free) GUI for postgres. It's not without its own issues (mostly with missing keybindings and focus issues) and it's ugly but it is at least functional.
But the find panel is the sole reason I cannot use ST2. Every time I bring it up I can't remember what button does what. And then I get stuck in the panel and have to click to get rid of it. Or hit escape.
But if I hit escape before hitting enter it assumes I didn't want to search after all and scrolls the viewport to somewhere random. Even though the term I wanted to search for is clearly highlighted on the screen.
It's a very very frustrating experience and even my co-worker who uses ST2 every day for the past year or two still gets tripped up by the find panel.
If I had a way to import the TextMate 2 find dialog into ST2 /3 I would buy a license.
I really wish I could find something like Sequel Pro that worked with PostgreSQL. PgAdmin III is.. functional but weird.
I've been tempted to add support to Sequel Pro myself but I don't know much about ObjC.
The explorer is metric in a lot of places. The engine is SAE since it's based on the 302 which was originally designed in the early '60s. Pretty much anything that was designed from the mid 80s or later will be 100% metric hardware unless it needs to work with something that isn't. And even then it'll will sometimes be metric until it hits the non-metric piece. For example, the Tremec T-5 transmission is metric but mates up to the Ford 302 which is SAE.
So basically, it's usually metric except when it's not.
A slow cooker/crock pot keeps a consistent (and relatively low) temperature for a period of time. Some have timers, some don't. Some have thermostats some just have high/low settings.
Also, selling at $1 you're only going to make $0.67 or so per transaction (maybe less depending on how you get bilked in fees). You're going to have to do a lot of volume to make money selling at $1.
I did some brief searching and it seems like the time limit depends on several things (including type and amount of charge and physical location of the vendor). It could be as little as 45 days or as long as 540.
It's definitely become more common to get chargebacks over the years. Part of this is increased volume on our part and part of it is the CC companies becoming more consumer friendly.
Most CC companies have a 90 day limit on charges that can be contested. Amex is the only one that I know of that goes further back (1 year IIRC but it may be longer).
Stripe has decided to change that and will refund the $15 if you win. It's a nice change but in my experience the vendor rarely reverses chargebacks.
Mainly the clear demarcation between "work" and "home." Working from home I just make myself some coffee, walk upstairs, and I'm working. Or not, I may go down and work on my car or clean the kitchen. Working from an office I had the drive to clear my head and go into work mode. And then the drive home to get back into "home" mode. I couldn't let "home" bleed into "work" and vice-versa.
I also miss being able to go knock on someone's door and bounce an idea off of them. Now I have to type it out or fire up a skype session to discuss things. Typing in the chat room isn't easy and nuance is lost. And the effort of bringing up a skype session and the human niceties that tend to go with it (the "hey how are you?") and technical problems ("you need to upgrade!", "internet is slow!") make it hard and I tend to just not do it.
That said, working from home on my own projects is nice and I don't know if I could ever work in an office for someone else ever again.
It lead to a lot of frustrating moments though. I remember sitting there and fuming trying to figure out where a variable came from. (This was when C++ was starting to get popular and variables started popping up everywhere. I was trying to figure out where in the world a counter was being declared in a for loop. Turns out it was being declared in the for loop.)
A bonus of this process is that I made a TON of mistakes and was exposed to dozens of programming styles. Because of this I can just skim code and error messages and have a general idea of what to look for.
(I use Windows for games and for testing in IE. I use OS X as my primary OS. The below is from a few hours of using Win8 after upgrading last week. I have been using Windows since the 3.1 days.)
In Win8 you can click on the Desktop charm and get to the desktop. There is absolutely no way to get back to the Metro start screen by clicking on something on the screen. You have to go to a 5x5px hidden block in the bottom-left of the screen and then click on the start block thing. Or use the keyboard.
When in Metro you have to go to the bottom-right corner and then wait and then go to the middle of the right in order to access settings. Or something. I can't really figure out how I manage to get the right side menu to pop out. I just move it around on the bottom right side of the screen until something happens. I still can't figure out how to edit charms.
There is nothing you can click on to see all of your apps. You have to start typing while in Metro. I had to use Google to figure this out. A "find apps" or something charm would be helpful.
Win8 is so chock full of mystery meat navigation that I cannot use it with the mouse. I'm having to use the keyboard to do anything. And it's so undiscoverable that I can not recommend it to anyone that isn't a power user.
The Win8 UI is really bad. They'll make it better but as it stands now, it's awful and unusable for normal people.
So you want to detect a fail to spool? OK you need to put a sensor on the engine to detect speed. And one on the throttle to detect position. Maybe there is another way to detect fail to spool but this is what we're going with because linear and rotational sensors are pretty common and well sorted.
Now you need to make sure that those sensors are 100% correct before factoring it into your code. So you add another of each sensor. But what if one of those sensors is out of calibration or broken? You need another one to vote for majority. Ok so now you've got 3 sensors on both the throttle and engine shaft.
Nothing really crazy here and pretty common.
Now you've got to build the software to model the engine. Jet engines have a delay in spool times that depends on air speed, how fast you feed in the throttle, how fast the engine is already turning, and other factors I have no clue about.
Now that you've got the model setup you have to add in some hysteresis to keep things nominal and to deal with glitches in readings due to iPods and cosmic radiation and vibration.
And then you have to remodel the whole thing depending on which engine is fitted (there are 3 available for the 777 plus variations). And then you've got to test it.
Now that you've tested that you are able to detect a fail to spool situation you have to generate the model of what to do in various flight modes. And that depends on how much thrust was lost, air speed, altitude, attitude, rate of decent, wing configuration, weight, landing gear configuration, etc.
And then you have to test the flight model. And then you have to update the operational handbook to inform the pilot of what to do if the above fails to work. You also have to amend the inspection and maintenance books to inform the A&P how to test and verify the sensors. You also have to modify the flight recorder to record the sensor positions and software behavior. And you have to modify the sat recording and playback software to handle the new data.
You have to do all of the above because if the fail to spool code activates on a normal approach it can very easily lead to a stall and kill 200+ people. You want to be 99.99999% sure your code is correct.
You've now spent millions of dollars and years of development to replace something a pilot can detect in 3 seconds by simply listening and feeling to what the plane is doing. AND you have created a liability if a bug crops up.
I've been through all of these naming schemas over the years (including the OP's tbl prefix and your table_ column prefix) and honestly they don't help. At best they disambiguate a corner case and make for a lot more typing than is needed. At worst you end up with things out of sync and you have a view named tblFoo with a column named post_blah because you don't want to mess up something that was coded a year ago and needs to keep working.
Keep things simple, format your queries, be consistent and all will work about as well as it's going to work. SQL is ugly.
Say you are working on a feature in a branch and have made several commits. Now it's time to clean them up in preparation for a merge. You can either squash the entire branch into one revision into master and create a new commit message (git merge --squash) or you can rebase.
If you rebase, you can use interactive mode (git rebase -i) and rewrite your local history however you see fit. You can reorder commits, remove commits, merge commits, edit commits, edit commit messages, anything. It's extremely powerful and lets you make the history of your current branch into whatever you want it to be. I use rebase -i quite a bit to merge "typo" commits into the original commit. Used sparingly rebasing really helps to keep your timeline clean.
You can also rebase while in master but you should not go older than the newest shared commit (origin's HEAD) nor should you edit other people's code during a rebase.
I have flown at 12k for 1 hour and could tell that the air was much thinner and that going much higher would have started to impair.
I think that most commercial aircraft run somewhere between a 6k and 8k cabin altitude and as such a whole different set of rules apply. I don't know for sure - I'm only a private pilot.
Chrome also triggers the discrete GPU so I can't use it either. I'd really like to because of Safari's problems with the debug tools. I don't want to get used to Chrome when I can only realistically use it when on power.
I do like the single view but it really needs to have the timeline.
I don't know what it was doing but there was a python process that was using every bit of CPU available and a ton of swap.
This same machine can build ruby 1.9.2 in under 10 minutes. It took less time to download and refresh all of my installed macports (including postgresql 9.0) than it took to attempt to build pypy.
Many car LED tail lights are actually refreshed at (I'm guessing) 30Hz or so to keep from overloading the wire - They have a distinct look to them from the low refresh rate.
Specific errors should throw specific exceptions. That way I can handle the ones I know how to handle and let the others bubble up and either completely break the app to be logged and fixed later or get handled correctly somewhere else. With ErrorException, you have to look at the contents of the error message to see if it's an error you can handle or need to rethrow.
Just a short list I can think of now:
- Short array syntax. Completely optional but would clean up the language quite a bit. This has been proposed several times and shot down each for no real good reason.
- Promote complex primitives into objects. With the proper interfaces it wouldn't break any old code. Once this is done, deprecate the myriad of str* and array* functions in favor of the object methods. This also cleans up the "what order do i pass in the args" problem that so many people cite.
- Named parameters. Gets rid of passing in default params or an array blob for functions/methods that take lots of optional params. It also opens up the way for DSLs.
- Replace PEAR with something better. The quality of PEAR modules is really low and PEAR always seems to be broken one way or another.
- Add a list and hash type. PHP's array is very slow for some cases, and sometimes you need to enforce the datatype you're working with.
- Use exceptions for errors. Could be a runtime flag to prevent breaking things. It's incredibly easy to write bad code because PHP make it easy to ignore problems. Things like functions that connect to the db or trying to retrieve data from a stream don't throw exceptions on error.